One thing that hasn’t been mentioned yet so far is that Erlang (and Elixir) are pretty good at hiding system details. It’s a virtual machine (or OS) on top of which your applications are running. And most code would just run fine on any operating system (disclaimer: haven’t tried Erlang on Window since a very long time). In some other languages, you have to choose between one of n competing thread or async implementations, zillion different ways to do locking - possibly unsafe, and one library might use this implementation, the other that and both do not work well together. Erlang just got this right from the beginning - it provides powerful concurrency building blocks like almost no other language.
mneumann
DidactMacros
Ther internet is a medium of communication. OTP supports communication and coordination across complex systems with minimal downtime (communication breakages).
OTP can also be used for complex software system where different components communicate with each other, even though the system itself is on a single device.
0
mpope
Something that I often don’t see listed is the powerful live debugability, which is especially useful under duress in production. Another amazing book by @ferd is Erlang in Angler, which touches on this. Compared to debugging production issues in Java using things like JVisualVM and remote IDE support, I think the ability of attaching a remote node and dropping straight into the shell to look at ETS tables, change process state, call processes, and made code changes is super powerful.
5
D4no0
Indeed, having the possibility to just spin up a remote console to your production instance is magic even to this day.
In the world where software inevitably breaks, having the option of debugging the production environment without downtime or needing to do redeploys is invaluable sometimes.
2
tristan
Rebar3 Core Team
This.
Observability is a huge part of what makes the BEAM great to use in production. I dread maintaining anything else in production.
1
sodapopcan
I missed this—this is a great comment and exactly how I feel about Elixir. I always say it’s a great mix of elegant and scrappy. And I don’t use “scrappy” in a negative sense at all—it’s just another way to say “pragmatic” though instead of picturing a stuffy academic, I picture someone getting stuff done. I believe it was @D4no0 who called with a “ghetto monad” 
We don’t have a codified bind, but we get on with with just fine, and it’s much easier for everyone to grok. Want partial application? Here ya go: mod_2 = &rem(&1, 2). You mad cos it’s not automatic? Sure, could be cool, but I’m certainly not yearning for it 
(the “object first” convention makes it a non-starter anyway).
4
AstonJ
Some excellent points already in this thread, and since it’s open on my device (I haven’t been able to resist it!) I hope @sasajuric won’t mind be showing you some of what he says in his book - I read it last night and immediately thought of this thread!
So technically, there are few languages and runtimes that come close to Erlang and Elixir, but there’s more to Elixir than just technical merit. It’s something I hope to cover in a blog post one day but one of my favourite things is how it, and projects like Phoenix, show you a better way.
Often when programming in another language I used to think to myself, surely there is a better way!? And that’s exactly one of the things I felt Elixir, with people like José and Chris, were promising - because they came from the same languages and saw the same pain points and issues we did.
This is why you hear things like Phoenix is not your app, and why Elixir and Phoenix are a little bit more explicit - there’s less ‘magic’, and the magic there is is arguably better balanced. I also like how we’ve got a few different ways to build apps, so you could have a Phoenix monolith (so a bit like Rails), and at the other end you could have an app made with Umbrellas (or Prag Dave’s microservices inspired architecture as per his Elixir for Programmers course) and then, in the middle, you’ve got Phoenix Contexts, which is an example of what I mean by Elixir (in this case Phoenix) showing you a ‘better (sane) way’.
And there’s loads more! (But you’ll have to wait for my blog post if you’re interested in my thoughts on this! 
)
In the meantime, why not join our Elixir In Action Book Club? Saša Jurić, the author of the book is taking part as well as the mighty @bjorng - who is not only one of the core team members of Erlang but also one of the 'B’s in BEAM 
6
sasajuric
Author of Elixir In Action
There’s a lot of potential for concurrency even in simpler systems. I gave two talks in the past where I tried to demonstrate this:
7
LostKobrakai
Yeah, it’s also everywhere unless you’re working on a highly synchronous possibly embedded problem:
3
tj0
100x.
And even more maintainability due to:
- common patterns in OTP
- pragmatic functional code that can be written without knowing group theory
- stable packages and slow churn in the ecosystem
2