Have you moved away from elixir? If so, why?

I’m not “moving away” from Elixir but experimenting it, at the moment.

I’ve been learning and experimenting Clojure on a project last year.

I’m currently trying to write a client/server app to exchange files in a secured way with Elixir. As this is not a Web application, I don’t use Phoenix.

I’m not coming from the Ruby world nor from the Erlang world but from the Basic/Pascal/C/C++/LISP/SmallTalk/Python/Tcl/Java/JavaScript/Clojure worlds.

So, my 5 cts of Elixir newbie criticisms at first glance…

  1. Adoption: To be honest, no one knows Elixir around me and very few in my country (France). So, no recruiting in view…
  2. Learning curve: Beside its (misleading ?) clean syntax, Elixir is not an easy language to learn when you have to fully understand and correctly use all the OTP stuff (genservers, supervisors, …). And if you don’t use the OTP stuff, why choosing Elixir ?
  3. Erlang: If you want to do something a bit serious with Elixir then you ALSO HAVE TO LEARN Erlang and to juggle with both syntaxes. Not necessarily “for your great good” ! :smiley:
  4. Libraries: Some libraries are clearly oriented by the particulars needs of their authors and sometimes “forget” some parts of the domain covered. Sometimes too, some unwanted “scories” arise (such as polluting logger messages)
  5. Documentation: The Elixir official hexdoc is nice but some libraries hexdocs seriously lack exemples or explanations. And when you have to switch to erlang docs (point 2), that’s worst again: nearly unreadable by a neophyte like me and sometimes, incomplete (no ssh_sftpd_file_api doc for instance ?)
  6. Books: Some of them begin gently then, at the middle, a “big step” of complexity and… you are definitly lost ! For some others the “big step” comes directly at the beginning…
  7. Videos: I didn’t find so many free “technical” (ie courses, not conferences or presentations) and progressives videos (except Tensor Programming and Alchemist Camp) as I did with JavaScript. In french, only one (Grafikart).

In conclusion, I would say that compared to most others languages that I learned, Elixir has to be earned !


Because great frameworks exist that take care of those details for you, so you get the benefits without the need to learn it. This is probably why Phoenix is so popular. If you aren’t developing for the web then yes, you will probably need to learn more about OTP upfront. Otherwise you can ease into it.


It’s been at least a year now … did anyone ask you yet? If not, I will, re:
how do you feel about Rust vs. Elixir (and/or do you have more thoughts about “possible reasons to move away from Elixir”) now?

1 Like

I’m on a love and hate relationship with Elixir. On the love side I think that BEAM nailed it, it’s just amazing. But I freaking hate the fact that the language is dynamic typed + bad tooling = hell for me.
Maybe Gleam can be the answer that I’ve been waiting for.
For now I’m trying to learn Rust, Zig and Crystal while I do most of my code with Go.

1 Like

Which tooling in particular do you find difficult? mix, hex and the docs are some of the best in any language IMO.

I’m also keenly watching Hamler, the rate of development on the github repo is amazing! :smiley:

1 Like

Same. It’s very satisfying for my personal stuff.

1 Like

Elixir and Rust aren’t rivals. I am currently starting several projects where they work together quite fine.


I wasn’t suggesting the contrary. I’m new, just stumbled across this thread, and was responding to a post from over a year ago.
The OP had mentioned using both languages, and had joked about being asked about his opinions in a year—so i thought I might.

With the standardization of Rust’s async / await primitives and libraries starting to adopt it, I feel like the BEAM VM (the runtime of Erlang / Elixir / LFE / Alpaca / Gleam) might have some true competition in several years.

But I wouldn’t wait. Elixir is an amazing orchestrator and I don’t feel like I am exaggerating when I say that likely 80% of every commercial programming projects out there can be improved by using FP. You can achieve a lot with Elixir alone.

That being said, there do periodically pop up threads here about people who are sort of angry that FP (and immutability of data by default) isn’t a good fit for their problem and start to passionately claim that Python / C++ / what-have-you is “better than Elixir”.

In these cases it’s very important to analyze the problem and find a good fit. I’ve already off-loaded work from Elixir projects to Rust functions at several places because some data structures really do work much better in a mutable world, and coding the same logic in immutable structures is a dying art (which I am not good in, I admit).

So back to your question: I’d still say do most of your app in Elixir (provided most of your app benefits from the almost-universal strong sides of functional programming and asynchronous / separate actors) and when everything is working, start measuring and replace the hot paths with native functions (C, C++, Rust, Zig, Nim, D, whatever floats your boat).


There is serious work on making a statically typed Erlang so there is hope. If you are into static typing :wink:


Is this what Facebook is working on, or someone else is on it?


I got very excited when I’ve seen a Facebook employee’s announcement on this very forum that they are working on statically typed Erlang – but judging by the fact that they were last known to hire for that team still, and the amount of time it takes for these things to take shape, I wouldn’t hold my breath.

For all the love I have for Erlang and Elixir, I fear its far future lies only in being a compilation target (e.g. Rust compiling to Core Erlang). Still love Elixir a lot!

Yes, I was referring to what facebook is working on. And they are coming along quite nicely.


Would the BEAM be a good target for Rust? It is very very Erlang specific and if rust can be implemented efficiently on the BEAM then it is basically another form of Erlang.


Very likely not. It would take the form of a reduced subset of the language (akin to how there are Rust libraries that consciously avoid using the standard library so they are portable to embedded targets). Which would introduce confusion.

Mostly thinking out loud. I wonder how several separate such efforts can be united – Lumen, Facebook’s work on a statically typed Erlang, Rust’s async capabilities… Probably never going to happen though.

1 Like

This thread is such an informative thread and I feel obliged to share my perspective. Disclaimer: I don’t write in elixir for a living.

I am attracted to elixir precisely because it is not mainstream (yet). Why would anyone learn to program differently if it is not to put food on the table? The only reason I can think of is for fun. Lisp was fun, Smalltalk was fun, because you don’t need to read inches thick books and write boring boilerplate code before you can do anything meaningful. Now that Lisp and Smalltalk are too simple to tackle problems of modern days I have to move up the ladder. I’ve searched long and wide and only this year I found Elixir. In terms of complexity it is the next level up for me, but more importantly, it is still fun.

If we cannot convince the corporate to adopt elixir from the top down, try to do it from bottom up. When java/C#/node.js developers come back home and work on their pet elixir projects and feel so much blissful compared to the dread of their day job, we are winning.


That’s what I did, several times. People were just like “ehhh, no, please don’t change our tech stack” and I went ahead and ignored them and showed them that Elixir brings real, immediate, noticeable business value (we’re not even talking about developer quality of life).

I have zero moral problems with such a behaviour from my side. If you’re too rigid and set in your ways, I’ll go out of my way to do the job that I was hired for – and maybe educate you in the process.


Folks, this thread has been running for too long and it is probably a bit intimidating for people to join given the messages count.

Most recent discussions deserve to be their own thread and I believe we will have more participation if they are done as so, so I will go ahead and close this discussion in order to promote the new topics.

Thanks everyone for contributing to the discussion!


I think you are wrong about Lisp and Smalltalk are too simple to tackle the problems of modern days. While they may be perceived as being too simple their simplicity actual hides extreme power which allows them to tackle anything and often better than modern more complex languages.

Getting the simplicity right is the hard and difficult part but once that is done there are no limits to what complex systems you can build on top of them.

A Dijkstra quote I love which is oh so true:
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”