What's all this fuss about Erlang? (2007)

From what I've read, Go's runtime just isn't compatible with the kind fault-tolerance that Erlang provides (nor was it meant to). It lacks process monitoring, lacks process isolation, has a pause-the-world garbage collector, etc.

Not a knock against Go, just pointing out that the design goals were different.

* A better concurrency model. Lightweight processes vs callbacks and futures. Or even channels. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process.

* Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning.

* Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years.

* Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge case.

Some people might prefer Elixir and that's fine, they are great friends. I personally like Erlang, I think it is simpler. Someone new coming from Python or Ruby might like it better and also it has very beginner friendly community. Jose Valim and and other authors really put user-friendliness and approach-ability at the forefront. I really like that, mad props to them.

Sure, it can be hard to read because you can write the same thing in tens of different ways and some people abuse it, but if you don't and your team does not, you end up with a beautiful code base.

Based on my experience of almost a decade in the embedded/safety space, this isn't true. Based on my experience as an end user of software on computers, phones, and tablets, I'm also not inspired by the crashes and performance snags I see. Even when it's safe, it's often slower than necessary thanks to unneeded locks by being too conservative (or due to refactorings which made the locks unnecessary but still present).

I agree it's not too hard. But it requires more thought and deliberation to make concurrent code in C/C++/Java than in Erlang than most developers seem willing to commit to the task. Paired with the built-in features of OTP to the Erlang platform, it beats the stock distribution of many other languages for reliability/safety of concurrent code. Those depending on external libraries can never seem to agree on just which one to use. It's too faddish to be reliable for maintenance over the next decade or five.