Ask HN: Who Regrets Choosing Elixir?

We inherited an Elixir project. After a year of irritations, we re-wrote it in Go and never looked back.

The combinatorics of having to deal with two different string types, two different throws (catch vs rescue), two different versions of each function (exception throwing vs error returning) in most of the base libs, weak typing, weak documentation, and the constant churn of dependencies because the language developers like to change things "just because" (i.e. regular re-naming of built-in functions for "consistency"--several builds broken because they just had to add/remove an underscore in one identifier or another).

And when things go wrong, we'd often have to dig-down into Erlang errors and libs the same way we would with Java errors in Clojure, so now we have two languages we've got to get everyone up-to-speed on.

When it got to the point where we were avoiding point upgrades in fear of how much of our code it would break, it was clearly time to move on.

   warning: System.cwd/0 is deprecated. Use File.cwd/0 instead
   warning: String.strip/1 is deprecated. Use String.trim/1 instead
   warning: Integer.to_char_list/2 is deprecated. Use Integer.to_charlist/2 instead 

Late to the game but wanted to add a reply to this. I chose Elixir for a side-project about 2 years ago now, and switched to Elixir full time 6 months ago. Absolutely no regrets. It definetely took a while to learn how to write decent Elixir code, but I think that's true of any language. My side project was my first Elixir project and it's gone through some serious iterations as I've learned various early things I did aren't ideal. Now I'm using it professionally and I'm so glad I am, it's wonderful to work with when you've got some experience in it and feel comfortable with it.

Some of the things that tripped me over early were: * Deep case statements when pattern matching functions would have been clearer. * Not using type specs. * String vs Atom keyed maps, I thought I needed to have a consistent approach but later realised they're both useful in different circumstances. * Over-use of exceptions (throw/raise). In the end I realised you generally don't want to use these except in really specific cirumstances. One such example is when you want to totally fail and exit a deep stack which would otherwise require loads of case statements to bubble up an error. But usually staying away from these is the right call. * Multiple forms of functions (ones which raise and ones which don't). While having both is useful in libraries, the rule of thumb really is to stick to the one which doesn't raise and handle the potential issues (ie: nil being returned). Only use the one which raises when you need to kill whatever you're doing. In general I don't write both forms of functions for my own code though.

Once I got past those and other teething issues it's been wonderful. Even language version upgrades have been pretty easy and that's often a pain in other languages. Now that the languages is "mostly complete" we don't see much in the way of breaking changes which is great, the rare deprecation perhaps but usually you can just upgrade without much of a thought and reap the performance benefits.

For context, I was using C#/.Net professionally before and TS/JS (node) for side projects before picking up Elixir.