What do you think are Erlang's biggest advantages?

We often get threads like this on the Elixir Forum, so I’m really interested in hearing the perspective of Erlangers - what do you think are Erlang’s biggest advantages?


I think there are many advantages with Erlang and it is hard to pick the biggest one. It also depends on what you are comparing with. Below I list some big advantages with Erlang.

  • The support for concurrency with processes and message passing built into the language and runtime system.
  • The SMP (Symmetrical Multi Processor) support which makes it very easy to utilize the power of a multi core CPU. The support for concurrency and processes was already present when the SMP support was added which made it super easy to take advantage of multi core CPUs without almost any changes to existing Erlang applications.

I intend to list more of my favorite advantages in coming posts.


In my opinion our biggest advantage is how we can reason about errors. Fred Hebert explained it nicely in The Zen of Erlang:

If the OCR process dies, it gets restarted. If it dies too often, it takes its own supervisor down, and that bit of the subtree is restarted too — without affecting the rest of the system. If that fixes things, great. If not, the process is repeated upwards until it works, or until the whole system is taken down as something is clearly wrong and we can’t cope with it through restarts.

There’s enormous value in structuring the system this way because error handling is baked into its structure. This means I can stop writing outrageously defensive code in the edge nodes — if something goes wrong, let someone else (or the program’s structure) dictate how to react. If I know how to handle an error, fine, I can do that for that specific error. Otherwise, just let it crash!

This tends to transform your code. Slowly you notice that it no longer contains these tons of if/else or switches or try/catch expressions. Instead, it contains legible code explaining what the code should do when everything goes right. It stops containing many forms of second guessing, and your software becomes much more readable.

Supervision lets us spend more time on business problems instead of avoiding crashing the entire OS process, and this advantage grows with the size and criticality of our services. Whereas other languages need perfect attention to detail everywhere in order to avoid tearing the whole system down, we only need that in our error kernels, and it’s hard to overstate just how amazing that is.

Put another way, our biggest advantage is the code we don’t have to write.


Yes I agree that this is one of the BIG advantages. It was next on my list and I think it could be called “support for making robust systems”, where you organize your application into processes in a natural way and then supervisors spawning and supervise those processes. If one process crash for some reason the other processes will continue to run without disturbance (in most cases). If you take a telecom example where you have an Erlang process for each Mobile phone a crash in one of those processes will only impact or disturb one user. The crashing process would typically be restarted by the supervisor.


Yep, but I think we lose a bit of nuance by leaving it at making it easy to build robust systems. Erlang (et al) is unique in letting you leverage robustness into productivity, and I think that’s a huge advantage in and of itself.


Often I try to raise the awareness of other programmers about how to write reliable programs, especially concerning multi threading and distributed systems.
And that’s exactly where Erlang shines :slight_smile:

But why I’m really using it: It’s just fun to write :stuck_out_tongue:


The functional language for the real world problems. It is the only high level language that started as a corporate sponsored project and have fully transitioned to the open source development model, and is still striving after so long.


Easy, the whole BEAM community … Without enthusiasts contributing and promoting languages we would still work on Assembler or similar level. Erlang’s biggest advantages are our community biggest advantages. Many people said that we are most welcoming. Together we changed how modern development looks like in 21st century.


The biggest advantage is the barrier to entry. It ensures that Erlang developers are almost exclusively above average individuals. This in turn increases the quality of interactions you have when asking questions and whatnot.

The biggest drawback is the barrier of entry. Because there’s only so many Erlang developers, there aren’t many who end up having the time or energy to promote the language. This in turn leads to a smaller number of developers than could be. Chicken or egg problem.


Proximity to the real world representation: the actor model. Unbelievably simple but so beautiful. Even though sometimes I wish there is more than “message queue” (after all, I have two eyes and two ears), but imagining how hard it would be to even model that…


A huge amount of functionality that is to some extent not even fully documented, which is also not bad because Erlang/OTP is an open source project. With Erlang, one person is able to create incredibly powerful tools and applications in a short time. Erlang has stood the test of time and he kind of dinosaur :t_rex: that has occupied its own niche.


actor model and OTP - biggest advantages.


I think keeping the language a moderate size is a great advantage.

Things can be small.

To name a few:

  • no global data;
  • no namespace (we do not have things like: a.b.c.d…, M:F/A is simple to reason about);
  • things are flat (processes can talk to each other directly, no need to get through a list of layering…);
  • I can put the entire language into my limited brain (memory), no swap is needed;

I realize this is a trivial point but using M:F (as opposed to employing import which I don’t see that often) is really useful as lightweight documentation. More typing, sure, but I read code more often than I type it.

Maybe I’m none too bright but I find this easier to deal with – especially with new codebases – than Elixir’s import Module or (gasp) Python’s import module as NonceNickname. If nothing else, it allows grep to work.

(Okay, this isn’t Erlang’s biggest advantage but I’d be chagrined if it changed.)


Erlang also have -import(Module, Functions). statement, so that is not much different there.


It’s true, of course, but it doesn’t seem to get a lot of use. For instance, in the 632 3rd party library source files in a recent project, only 12 have an -import directive. Of those, only one instance imported from a stdlib module.

Perhaps it’s more correct to say the culture is different?


I think it goes without saying that Beam is the biggest advantage of Erlang, but then again, it’s also the biggest advantage of the million other languages that is atop that. Erlang’s just the first one.

Let me speak of the advantage of Erlang, the language. And this is based on my experience and my world view and could totally be not viewed as an advantage of any sort by others :slight_smile:

Okay, when I first encountered Erlang, back in 2009, I was baffled and confused by the syntax. My eyes hurt with pattern matching, case-centric differentiation of atoms versus variables, and comma/semicolon expression separator. And my rejoicing period of being able to learn the language faster than any other (Yes, I learned the language fast) didn’t last long as I started hitting walls, each walls having a PID for their names.

And there lies the greatest advantage of Erlang, its unfamiliarity if learned decoupled from OTP. If you treat it only as a language, solve a couple of Project Euler (Advent of Code didn’t exist back then) puzzles, you won’t enjoy it. But only after you understand the way of the OTP, its behaviours, and appreciate its use cases, Erlang starts making sense, and there exists that aha moment where you are empowered both with the framework and the language concurrently (no pun there).

Other languages, like Java, Go, Elixir, F#… they all can be fun as a “language-only”, I have seen people fall in love with Elixir the language, and touched OTP later when faced at work. But Erlang is not enjoyable unless it is learned in tandem with the platform. And both – the platform and the language are easier when learned together, somewhat not in isolation. This is a property Erlang has, which I believe no other language does. This includes other beam languages too.

I have seen many programmers try out Erlang and hate it, then gets into Elixir, hits the Beam, gets back to Erlang and sees it differently. Had they experienced Beam and Erlang together, they’d learn both faster. And seeing OTP behaviours through Erlang’s eyes enlightens faster than seeing it in any other Beam language’s eyes in my opinion.

This is a unique property of Erlang and the greatest advantage of it — in my opinion.


An excellent point and one of my biggest bugbears with, say, C++ where you grep for fred() and find 5 freds, of which 0>N>=5 of which implement the code that’s actually running. (In a similar vein, I hate how C’s typedef is so commonly used to obfuscate a struct, enum or union. Linus Torvalds also has words to say on this.)