from Hacker News

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

by techiferous on 8/5/17, 12:58 PM with 96 comments

• by bjz_ on 8/5/17, 2:23 PM

  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...

• by tatersolid on 8/5/17, 1:36 PM

  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.

• by whitepoplar on 8/5/17, 1:32 PM

  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

• by atombender on 8/5/17, 2:39 PM

  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.

• by jesses on 8/5/17, 2:46 PM

  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.

• by Sailias on 8/5/17, 2:10 PM

  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.

• by hawkice on 8/5/17, 1:36 PM

  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.

• by aczerepinski on 8/5/17, 3:48 PM

  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.

• by tmorton on 8/5/17, 2:03 PM

  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.

• by albertgoeswoof on 8/5/17, 1:29 PM

  99% of software developers haven't heard of elixir

• by thesmallestcat on 8/5/17, 2:01 PM

  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).

• by Rjevski on 8/5/17, 1:48 PM

  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.

• by swat535 on 8/5/17, 3:10 PM

  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?

• by andrenth on 8/5/17, 5:40 PM

  Personally I'm waiting for Alpaca :)

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

• by becga on 8/5/17, 2:32 PM

  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.

• by user5994461 on 8/5/17, 1:58 PM

  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.

• by maxxxxx on 8/5/17, 1:55 PM

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

• by qaq on 8/5/17, 1:31 PM

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

• by DeepRote on 8/5/17, 1:34 PM

  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