Ask HN: Who is not betting on Elixir and why not?

https://news.ycombinator.com/item?id=14935474

by techiferous • 9 years ago

69 96 9 years ago

news.ycombinator.com

It's easy to find people talking about why they took the gamble to switch to Elixir. I'm interested in those who have tried out Elixir in production (or a serious prototype, not just dabbling) and then decided not to use it. Why not?

albertgoeswoof• 9 years ago

99% of software developers haven't heard of elixir

qaq6• 9 years ago

Given the extent of coverage on HN I would say there are very few devs. on HN who haven't heard of Elixir.

thehardsphere• 9 years ago

Devs on HN are a very small subset of the developer population.

ZenoArrow5• 9 years ago

Not all devs read HN. Based on conversations I've had with devs I've worked with, I doubt it's even close to a majority.

hpcjoe• 9 years ago

I've been reading HN for years, and this is the first time I've seen/heard of Elixir.

Sample size of 1, self selected, your mileage may vary, things in the mirror are closer than they appear. That is, it isn't really meaningful as a data point in isolation.

I only clicked this link out of morbid curiosity, on why someone would make such a presumptuous statement. Put another way, the question asked is heavily loaded. I was more interested in the discussion around the statement, to see what people thought, than the content of the question.

You may have what you and others consider the greatest thing since sliced bread. And you might not fathom why others would not see it that way. After all, it is the greatest thing since sliced bread. It is a dessert topping and a floor wax (obligatory SNL skit reference).

Even with all this, the criteria for success, oddly, rarely has being "the greatest thing since sliced bread" as part of the core elements of being successful. You don't need to be superior to be successful (though I am not stipulating that Elixir is superior, I've never seen it, used it, etc.)

The question is why would people choose this over others? What benefit would this language provide that others simply cannot?

I've used many languages during my professional and educational life. I've never seen one that was universally appropriate for all tasks. I some that fit the majority of tasks I worry about, very well. I've seen others fit very poorly. I have no opinion on Elixir, other than to note a small vocal group wondering aloud how anyone could not use it.

Reminds me of Python in the 90s.

sotojuan• 9 years ago

99% of developers don't read HN or care about new languages.

Ok maybe 90% :-)

qaq6• 9 years ago

Lack of comments can be interpreted in positive light for Elixir I guess :).

always_good• 9 years ago

I doubt everyone chomps at the bit on a Saturday morning (for most of them) to remind others on the internet that, yet again, there are no silver bullets.

hellofunk5• 9 years ago

That's a bold assumption to write only 30 minutes after the OP posted, and probably only a few minutes after it hit the front page.

21stio• 9 years ago

or there are few people that have used it in production :P

whitepoplar2• 9 years ago

I love elixir, but it's just a language. There are other great languages, too. Use what fits your brain. Don't listen to what others carry on about. The only downside I can see for me is that there are fewer, less battle-tested libraries available as compared to, say, ruby. The most unexpected benefit of getting into elixir has been the community--it's a positive place to be, and I feel it has made me a better, more confident programmer. <3

zaphar• 9 years ago

One of the great things about using different languages on my off time is that the number of things that fit my brain has grown over time. It doesn't actually take that long for an experienced polyglot programmer to pick up a new language.

I think use what fits your brain is the kind of advice that sounds good but does most people a disservice. At work use what allows you to ship high quality code, on time, within the business constraints that you have. But you'll have much better options in your career if you take at least some time to expand your brain so more things fit in it.

whitepoplar2• 9 years ago

I guess what I meant by "use what fits your brain" is more along the lines of, "try a bunch of languages first, then use the one you like most". Without experimenting, you'll most likely be lulled into thinking your first language is the one that fits your brain best. I would disagree with the notion that a language fits one's brain after you've picked it up. I really don't like javascript, for instance, and I've used it quite a bit.

DeepRote• 9 years ago

Elixir is just an AST transform for erlang/otp. I like erlang and there are features that I wish it had sometimes, but elixir couldn't be further from what I'd come up with if I decided to fix it myself. It takes all the bad parts of lisp, shoves them into a bad ast format, and crunches it all down to beam code. It's just a terrible implementation of a terrible idea.

I am actually moving components of my apps away from erlang to f# to shield it from the destruction of beam that elixir will bring about.

2/10

hellbanner4• 9 years ago

What is elixir doing that's so bad to .beam format?

ZenoArrow5• 9 years ago

I wouldn't worry about it, the GP is clearly trolling, there's nothing of substance in what they're suggesting.

tatersolid3• 9 years ago

Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor. If you "guess wrong" on a language you're looking at a multi-million dollar rewrite down the road which is an unacceptable risk. It's also very difficult to find staff or contractors who are familiar with new or unpopular tech. Basically any industry that deals with "real money" or "life and death" intentionally does not follow developer fads.

hellbanner4• 9 years ago

Would you consider Erlang to be a proven language?

http://www.erlang.org/about

ZenoArrow5• 9 years ago

Erlang != Elixir. They run on the same VM, and you can reference Erlang code in Elixir but that doesn't make them equally production ready.

tatersolid3• 9 years ago

No.

You can't hire or rent devs that know Erlang without a multi-month search in most markets. This is a non-starter for most businesses.

Train them on Erlang yourself? Why? Any possible productivity benefits offered by Erlang over a more mainstream option are dwarfed by training and hiring costs.

Nobody gives a shit about hot code patching in real business systems; the telco switch architectures which demanded such features are basically bonkers and unnecessary in a packet-switched world.

sirn2• 9 years ago

It's also worth noting that, VocaLink, one of the well-known payment systems company do use Erlang for their products. I have also seen that Visa/Mastercard has been looking for Erlang developers as well.

hellofunk5• 9 years ago

But Erlang and Elixir are not the same thing. Erlang is proven in a major way thanks to telecom industry. That they both use the same VM is not enough.

usgroup• 9 years ago

... except Clojure is used by prominent banks and it's all those things.

hellofunk5• 9 years ago

Clojure has been around longer and is generally more mature than Elixir. It also has a much much larger community.

zerr4• 9 years ago

Is it? It seems to me that outside HN/reddit Clojure is not a thing actually - take a look e.g. at TIOBE index.

qaq6• 9 years ago

Well Erlang Solutions supports Elixir in a major way. Goldman is running a lot of core critical systems on Erlang (supported by Erlang Solutions as far as I remember).

user59944614• 9 years ago

They have the brand to recruit with the budget to pay first class support and contractors at > £1000 a day. Do you?

Even with that, it's still difficult for them to recruit.

rhblake• 9 years ago

I believe Klarna (dominant payment service provider in Sweden, handling >$10B/yr) is starting to do some stuff in Elixir (having already invested heavily in Erlang).

tmikaeld• 9 years ago

Started? I'm quite certain their entire API backend runs elixir. I've been an early user of their public APIs for many years, so I got curious and asked the developer in charge back then.

dagw2• 9 years ago

Coming from the banking industry, nobody looks at using unproven languages or frameworks unsupported by a large community or major vendor.

The 'banking industry' is huge. While what you say is true in many parts of the banking industry, I also know people in the banking industry for example who write and use an in-house DSL written Haskell for their day to day work.

tatersolid3• 9 years ago

An in-house DSL is madness and could only be achieved behind management's back. I hope the documentation is damn good. I bet they'll be over-paying the jokers who wrote it (as a form of job security!) for the next 20 years.

hawkice2• 9 years ago

All my new server-side code is in Go (where all my old code was in Elixir) because I wanted something I could build locally and deploy easier. The deployment story for elixir is... substantially worse than ideal, for, seemingly, no reason at all. At the time I was writing the deployment scripts, not only was the hot-code-replacement not going to work, even AOT compiling to .beam files was broken, with multiple 3rd party tools not helping.

iends2• 9 years ago

Elixir seems to have better abstractions at building CRUD apps (and websockets) than Go. Are you building CRUD type apps? Have you writing lots of SQL vs using ecto to be painful?

hawkice2• 9 years ago

Not exclusively CRUD apps, but some. I've not minded the DB work I've done so far, but I also don't mind SQL. Changesets are a smart API, but fundamentally aren't much different than normal SQL. Ecto is nicer for loading lots of joined data, but... eh. Hasn't bothered me not having it. So I'd be hesitant to say Elixir has lots of amazing APIs -- good, but not indispensable.

Rjevski2• 9 years ago

Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language. Maybe once Python starts to be obsolete I'll switch but in the meantime I can't afford spending time learning something new just for the sake of it.

whalesalad• 9 years ago

That's a really interesting (and, in my opinion, negative viewpoint)

I have been a Python developer since 2006/2007 and every time I depart to another community for a while, I return with a ton of new ways to think about problems. Not only that, you'll usually have a newfound appreciation for things in Python you might not have really cared about before (eg decorator syntax)

- Becoming a Rails developer was a game changer. The Pythonistas tout it to be 'magic', but it's really not. It's easy to understand what is going on. Once you use a tool like Rails in more advanced situations – every Python web framework looks like a horse drawn carriage.

- On a related note, reading Eloquent Ruby was one of the most epic nonfiction reading experiences of my life. After reading that book, I rarely see "programming magic" to be magic anymore. I understand it all. A lot of the knowledge from that book translates well to Python too, since Python and Ruby are very similar.

- Learning Clojure and using it day-to-day at FarmLogs has made me think more functional than I did previously.

It's usually not just the language that is going to open your mind - but the frameworks, tools and communities that grow around the language. It's like visiting a new country. You're gonna love certain customs and dislike others.

Anyway... saying you don't have time for something that will open your mind and make you a better programmer sounds like a grumpy old man who's missing out on the world.

davidgf2• 9 years ago

If I saw your reply before writing mine, I wouldn't have bothered responding :) Absolutely agree with every single word

kkirsche• 9 years ago

I would highly recommend you not hold true to this. Learning encourages growth especially in languages like elixir and erlang which offer a functional view of how to approach problems. This can lead to better use of functional Python functions and methods such as map, lambda, etc.

Whether you use the other language doesn't mean there is no benefit to learning it

davidgf2• 9 years ago

I wouldn't stop learning new languages. They are just tools, and knowing several of them lets you better judge how to face a new project/problem. I was (in fact, am) a happy Rubyist, but had to start working with Node and learnt to love the beauty of event-driven programming and prototypal inheritance. Now I'm learning Elm, as I'm quite interested in functional programming and event sourcing. I wouldn't say that any language is better that another, but knowing some of them and the principles they are based upon is helping me evolve as a developer and changes the way I code, regardless of the language I choose for a certain project.

dagw2• 9 years ago

I've come to pretty much the same conclusion as the OP. I used to love learning and trying new languages and I agree that learning things like C and Lisp and Haskell definitely made me a better python programmer. However over the past few years I've decided that python, while far from perfect, is the only language I've found that is good enough for everything I want to do. And more importantly I've realised that learning new languages is not the best use of my limited time. I'm much better off studying a new domain or practical application which I can apply python to than I am learning a new language do to the same thing I'm already doing in python.

rsyring• 9 years ago

Despite the naysayer replies you are getting, I understand this viewpoint. I'm also a Python developer, business owner, and family man...very little time for learning extra things. Right now, I have my hands full keeping up with changes/frameworks on the front-end, which is where my customers will benefit from improvements. Elixir is on the fringe for me, something I will keep an eye on, but won't seriously consider using unless it has significant developer mindshare in 3-5 years.

So, yes, learning is good. But we are still finite beings with limited time. Having priorities about what you will spend your time learning, and choosing Elixir to not be one of those priorities, is a legitimate stance. Thanks for sharing.

Rjevski2• 9 years ago

This is exactly my point. When I was a teenager with lots of free time I loved experimenting with new languages and stuff. Now I am employed and the little time I have outside of work I'd rather spend it with my friends and family instead of tinkering with tech. I do enough programming at work, I don't need even more of it when I'm home.

AlexeyBrin• 9 years ago

Personally I am a happy Python developer and I don't feel it's worth it for me (in terms of time) to learn another language.

This is a very limiting view of the programming space and world in general, hopefully with time you will understand that learning a new language will only help you to get better in your old language. You don't need to invest years in a new language to get the gist of it.

maxxxxx• 9 years ago

After reading the second paragraph the headline should be rephrased "Who has tried Elixir and then decided not to use it and why not?"

user59944614• 9 years ago

Don't use. You're gonna be in big troubles to recruit developers who knows that tech.

It's already an issue with Erlang. It's made 10 times worse with Elixir.

iends2• 9 years ago

Are you hiring developers who can't learn new languages?

timfrietas• 9 years ago

If it slows the team down significantly and that speed is not regained in either performance or development time, then I personally would not hire developers to learn X new language.

icedchai2• 9 years ago

Learning languages and using them to develop an actual production-grade product are two different things.

Pick something proven.

I worked in a Scala shop and people spent tons of time flailing about arguing over syntax, dealing with bad IDE plugins / slow tools, etc. They'd have been better off just sticking with Java.

iamd3vil3• 9 years ago

Why do they have to know the tech before? A good engineer can always learn new tech and I think as a developer who belongs to a company who uses Elixir in production, most of my colleagues who use Elixir didn't know about it before getting hired.

malloryerik• 9 years ago

And if they happen to love the tech, which seems common with Elixir, then they might also want to stick around longer. Uncommon technology can give a team cohesion.

skrebbel3• 9 years ago

We are hiring Elixir developers at talkjs.com and find it to be a very easy way to interest good developers. A lot of people have been hobbying with elixir and want to use it at work but can't in their current job. Also, currently it is hardly ever someone's first language so we pre-select to relatively experienced programmers.

thesmallestcat• 9 years ago

Erlang and Elixir are both fine languages, but the BEAM is slow and not suitable for anything computationally intensive. Extending your program whether via NIFs or Ports is a PITA. It's great for anything requiring many active connections like front controllers and P2P, but outside of that you're better off with Clojure if you want an FP with immutability IMO. I think that you need to be working on a niche concurrency-focused application, or have engineering manpower to burn, to justify using a different language for such a narrow case. Erlang library support still is not very good except for, again, concurrency-focused ones (gproc for instance).

tmorton• 9 years ago

I'm pretty strongly on the Elixir train, but here's where I see its greatest weakness:

On many platforms, the best practice is to have stateless application servers, with separate stateful data stores. On the other hand, the big advantages of Erlang/Elixir are in managing state along with your application logic.

In a vacuum, that can be a big win. But I'm worried that the advantages are not enough to overcome the weight of tooling, services, and best practices built around the stateless model. For example, Heroku explicitly tells you to avoid application state, and Docker is built around a destroy-and-rebuild ethos.

For my project, Elixir/Phoenix is great as a "better Rails", but I know I'm only scratching the surface of the platform's strengths.

jesses3• 9 years ago

I don't want this to feel like an ad, but https://gigalixir.com should help in this area. Its a platform-as-a-service, like Heroku, but it's designed to encourage stateful application servers by not doing daily restarts and supporting hot upgrades. Disclaimer: I'm the founder.

skrebbel3• 9 years ago

Very cool! Where do your servers run, and is there any callback planned in case your service gets discontinued?

Sailias• 9 years ago

We are using Elixir in production for a site with traffic that can spike in a short period of time.

Elixir has helped us reduce our costs by 1/3 and improve our API response times from 50ms to 5ms. (Ruby -> Elixir)

Using erlang/Elixir processes forced us to reevaluate the way we handle state and were able to find many ways to optimize.

I believe our code is now more organized, extensible and powerful. Our infrastructure is also more complicated, but much more fault tolerant as we have fallbacks for fetching data etc.

Deployment was pretty terrible but a simple scaleable solution with AWS is build with a docker container, push to ECS and launch ECS + ElasticBeanstalk and you're good to go.

bjz_3• 9 years ago

I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:

I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.

I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.

I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...

mbrock• 9 years ago

"interesting work in progress on this front though"

Any pointers?

bjz_3• 9 years ago

In my frustration while writing my comment I'll admit I was a bit weaselly there and didn't really cite anything. The Akka.Typed[1] project is working on type-safe actors, but looking at it again I'm not sure how or if they can do hot-reloading or ensuring that you can soundly migrate actors in-memory before starting a deployment. That would be super cool to see. Maybe something for Pony to look into? If folks know of any academic PL research on this front I'd be very interested. But again, I'll reiterate that it's a use case that lies at the very extreme end of our industry.

[1] http://doc.akka.io/docs/akka/current/scala/typed.html

zerr4• 9 years ago

excitement will eventually flow back to us on the back-end

Like e.g. Java, Scala, C#?

bjz_3• 9 years ago

Scala maybe, but it has its share of problems, alas. On a purely features level I'd definitely be looking for something with null safety, disjoint unions, pattern matchin with exhaustiveness checking, local type inference, and parametric polymorphism (ie. generics). These are what set a modern, nicely typed language apart from the more constrained, frustrating kind that caused many to escape to PHP, Ruby, Python, and now Elixir in the first place. We need a richer experience beyond that though in terms of ecosystem, compiler performance, teaching materials, etc. in order to really drive things in that direction though and get more back-end devs on board. Obviously something in our approach is not working - and it must be partly our failings. It's going to take a while to turn the ship around, but I still have hope!

runeks• 9 years ago

The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...

I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.

The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).

This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.

[1] https://github.com/runeksvendsen/rbpcp-handler

[2] http://www.parsonsmatt.org/2017/04/08/maybe_use_a_type_param...

[3] https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...

becga• 9 years ago

The deployment can be difficult to automate especially if you are attempting to inject application properties at runtime.

There are solutions out there,though documentation may not cover every use-case, especially if you are deploying to something like AWS or GCP (Not everyone can adopt Docker just yet).

The Hot-Upgrade is a great idea though you will have to do your research to integrate this with your Cloud Provider.

Overall I'm betting adoption will be niche, and primarily via Teams coming from Rails. Until a major cloud provider starts offering native support + the community grows to a sizable percentage, it will be slow to catch on.

atombender• 9 years ago

As someone who spent a long time in Ruby land, the last thing I want right now is another dynamically typed language.

I'm a big fan of Erlang and OTP, and really wish for that style of concurrency, failure tolerance and distributed computing. For me, the lack of static typing in Elixir struck me as a missed opportunity from the outset. The Ruby-like syntax isn't enough to change the game for me (I find it significantly less attractive than Ruby, but that's not important), even with macros.

Since I don't use Elixir, the above isn't necessarily a criticism of it -- I'm sure it's great. Just not for me.

Go is what I'm using now, and I've been playing with Rust and will probably start using that when I have a new project. I've been using Haskell for some side projects. I like OCaml a lot, but I won't touch it until multicore support lands and matures. For web projects, my plan is to transition everything from JavaScript to TypeScript, precisely for the type system.

No more dynamically types languages except for scripting.

jesses3• 9 years ago

Deployment is by far the biggest pain point I've seen in new Elixir developers. Developers use Mix in development, but then build releases using Distillery for production. There are a few gotchas and pitfalls that almost everyone falls into when using Distillery like using `System.get_env` and forgetting `server: true` in their `prod.exs`. Hot upgrades can also be a source of a lot of confusion. Configuring distributed clustering in production can be tricky especially if you're running on Docker/Kubernetes/etc.

That said, I built https://gigalixir.com to try and help with some of these issues and improve the deployment story for Elixir.

swat535• 9 years ago

I think this a great discussion topic. I am really glad that everyone loves elixir on HN but I would like to hear both sides to analyze the weakness and strong points of a given technology. This makes more a balanced discussion instead of just praising a language. Honestly I would personally enjoy a more technical scrutiny of a language / framework, especially from a technical site like this one. Does anyone have a good write up on something like this for Elixir?

aczerepinski• 9 years ago

We wrote a few small services in Elixir at work and I loved it. I had been using it at home and reading all the books, and would have been happy to commit 100%.

However, I don't think anyone else was getting excited about Elixir, or more broadly about functional programming. When it came time to choose a stack for a much bigger project, Go won out. The only specific complaint about Elixir I'm aware of is that ramp up time would be too long every time we bring a new dev onto the project. In hindsight I don't think Go is any different in that regard. A Ruby/JS dev either needs to learn pattern matching, macros, list comprehensions, and a bit of OTP for Elixir, or they need to learn static typing, pointers, goroutines, and idiomatic error handling for Go.

Personally, I'm happy either way. I'd still probably choose Elixir if it were my choice to make, but I'm loving Go too.

andrenth• 9 years ago

Personally I'm waiting for Alpaca :)

https://github.com/alpaca-lang/alpaca

Ask HN: Who is not betting on Elixir and why not?

Related Stories