Erlang vs Elixir

Just dipping my toe into Erlang and Elixir.

Seems there is almost 1-1 mapping between the two - with Elixir being slightly more concise but ultimately producing the same beam code.

Elixir seems to have more momentum behind it at this point - more new activity on github, more new books published - and some nice frameworks like Nx (neural nets) and Phoenix.

Any reason - other than habit - to prefer Erlang over Elixir?


Welcome @reymono!

I actually find Erlang can be more concise than Elixir in several occasions. Erlang is also a simpler language. At the end of the day though, you are right they are similar and because both run on the Erlang VM, they interoperate just fine. So there should be no problem to start with Erlang and add Elixir or vice-versa.

If you want to be practical, you can look at libraries and frameworks (do you have a need in particular that could push you towards one language or another?). And, if you have a team, you could decide together.


Erlang is the “core” language of the BEAM but, ultimately, it’s the BEAM that’s most critical in delivering the disruptive capabilities of things like OTP. Erlang is clearly a bit closer to that model but also more esoteric. It was made to run inside telephone switches by engineers whose priorities are made clear as you get deeper into it. Text handling and tooling were not major priorities (although both have improved vastly over the years) but resilience, concurrency, low overhead independent actors, conciseness and logic were the focus. Elixir comes from the Ruby/Rails community which was primarily doing web services on top of databases. Being willing to inject some “magic” to hide a lot of behind the scenes complexities and a focus on strong tooling to get you to your core use cases quickly were prioritized as well as syntax that felt more imperative and accessible to “normal” devs.

The Elixir community has come in and built on top of OTP bringing along this focus on tooling and “ease of use” which has forced/helped the Erlang community to appreciate some of the benefits of these things. Just a year or so ago I would say you can’t be a great Elixir dev without also knowing Erlang. But Elixir has now wrapped and extended so much of the BEAM/OTP capabilities in “native” Elixir that I would now say you can’t be a great Elixir dev without knowing OTP well. Either way - being a capable Erlang dev is going to help you greatly in being a capable Elixir dev. Fortunately the two interoperate quite easily.

The biggest general differences I see between Elixir & Erlang teams/devs is Elixir teams do tend to work on the assumption of a 3-tiered architecture where most requests ultimately hit a database. Erlang teams tend to appreciate the “orchestrate a bunch of actors” and make databases something that might be needed to cache data persistently but prefer to have distributed copies of live actors so databases aren’t really needed and then use far less complex databases (never an enterprise RDBMS model with 50+ tables) for highly domain specific uses. So figure out which scenario you find is upon you and arm yourself accordingly.

FWIW - my team defaults to Erlang especially for business logic and backend stuff. We do a lot of highly distributed high capacity work where hitting a database for each tx would simply destroy our performance. But when we build apps that have a lot of asynchronous web front ends we have grown to love Phoenix/Liveview (which is Elixir stuff) which lets us avoid having to spend a lot of time doing front end Typescript coding yet still give the users a remarkably responsive and capable user experience. Our Liveview apps generally don’t talk to Ecto databases, however, but rather Erlang actor processes from our backend efforts.

Both are great technologies. Elixir clearly is more accessible to newer devs with less formal engineering training (and maybe even to those!). Erlang is succinct and, once learned, amazingly powerful when you think in terms of capabilities per line of code to be maintained. It’s amazing what you can build with only the Erlang OTP distro and no other dependencies in a very short period of time. I think, eventually, when you hit the sweet spot on one of them pertaining to your actual needs, eventually you’ll discover the value of the other as new challenges present themselves. And there’s other languages existing for BEAM and that continue to be developed that may also play a valuable part.

Trust the BEAM and all who abide by it.

– Ben Scherrey


The differences between Erlang and Elixir are by now more cultural than anything else. I personally dislike Elixir syntax but there are plenty
of people who disagree. They are not the only alternatives. There’s
LFE (Lisp-Flavored Erlang), which I appreciate. There’s Gleam (find out
more at which is worth considering if you like static typing
by default. There are 34 languages for the BEAM listed at but many of them are no longer
actively maintained.

Erlang, Elixir, LFE, and Gleam can all call each other, so you should
probably consider personal taste and cultural “style”.


Erlang vs + Elixir

In my experience the further away i went from Phoenix app and more towards distributed system the less resources i found for Elixir and more for Erlang. Sure they were 20 years old but don’t let that put you off :smile:

I think when it comes to distributed systems Erlang still has some aces up its sleeve.
Common Test for example. (I do miss the nice assertion diffs from ExUnit)


Many thanks.

Plan to dive deeper into Erlang and OTP later - have read Joe Armstrong’s Erlang document and am currently reading Elixir in Action.

Elixir’s mix tool reminds me of Rust’s cargo - which is good.
Also feels like some of Rust’s pattern matching - e.g. match statement - is related.

Sometimes think there are more languages in the world than there should be - Erlang is different though; few languages put concurrency first. Will have a look at Armstrong’s PhD thesis also - surprised it is only from 2003.


Personal taste (probably formed from habit :). I prefer the Erlang syntax (I think it is actually often more concise) and prefer rebar3. So I’d suggest playing with both and going with what you like the best, and as you say the mapping is almost 1:1 so you can jump between them if find you need to work in the other for some reason.


Seems there is almost 1-1 mapping between the two

Last time I checked, Elixir compiled to Erlang, rather than directly to BEAM bytecode. So the mapping from Elixir to Erlang may or may not be surjective.


I assume most people starting with Elixir today do so because they think it’s the latest version of Erlang, in the same way that people mistakenly believe that C++ deprecated C.

I’ve never used Elixir because I was already fluent in Erlang when it arrived and I understood it to be meant to be more approachable so that wasn’t solving a problem I had. Given the increasing number of libraries for Elixir I’ll probably use it one day.

1 Like

I started my journey with Elixir, and that brought me to Erlang as well.

Learning Erlang made me a better Elixir developer. The deeper I went with Elixir, the more often I found myself reading Erlang documentation, so I had to become familiar with the basic syntax, at least to be able to read the documentation.

Elixir felt more beginner-friendly, but now I think Erlang is actually simpler.

You can call Erlang within Elixir code and vice versa, but the latter is a bit more complicated. Also, you need Erlang installed on your machine to code in Elixir, but you don’t need Elixir to code in Erlang.

Elixir has more third-party libraries available and that’s why I have chosen it over Erlang sometimes(I really like the Phoenix framework for example) but Erlang has a bigger standard library.

In the end both compile to BEAM so I guess theres nothing that one language can do and the other can’t.
It may be more convenient to use one over the other depending on the use case.

I like both languages :slight_smile:


I started with Erlang in 2020. I was able to implement a web server (using cowboy), use Mnesia for data storage and able to encrypt/decrypt client requests using Erlang’s public_key functionality. I found Erlang to be powerful, concise and absolutely indispensable when it comes to fault tolerance and stability. It is also an unforgiving language, so it makes you a better programmer. On this journey, I did try Elixir. I’m just not down with that syntax. All those do/def/end, defmodule. Not to mention the ‘:’ before an atom. Erlang’s elegance and simplicity are hard to beat.