[jlouis]

Let me add: more powerful and expressive languages can often get away with far fewer programmers. So if you measure in sheer numbers of people working on, or lines of code being executed, you get the wrong number count.

A rough estimate from Erlang, is that the typical Erlang program is 1/5th of the typical C++ program implementing the same functionality. And the Erlang program even handles unforseen events :)

[beagle3]

> A rough estimate from Erlang, is that the typical Erlang program is 1/5th of the typical C++ program implementing the same functionality.

And taking that to the extreme, J/K/APL is usually 1/100th of the typical C++/Java program implementing the same functionality. Unlike erlang, it's not more robust - but it's often faster (not because of some theoretical advantage - when you write 1/100th of the code with the right primitive, you have more time to think about optimizing it)

But as another poster said: Shh, don't tell anyone about our unfair advantage.

[oinksoft]

Ssshh, don't talk about Erlang/OTP too loud, they might realize how good it is ;)

[jlouis]

My stance is still the same as two years ago: Golang is a very decent language with a lot of interesting features. But the lack of direct address of fault-tolerance is what I am missing. In distributed systems, you can't hope to handle all kinds of failure scenarios. You have to punt at some point and assume that the problem doesn't ever happen in the real world. And that is where you need fault tolerance.

[codewright]

It's not really common or standard to rely on a cluster of VM instances to solve your distributed problems for you these days.

For most programmers: Statelessness is the default, replication and fail-over are the back-up plan.

Talking about Erlang's "fault tolerance" as if it's some sort of secret weapon these days (it was more important 10-20 years ago) is a canard and distracts from the better parts of Erlang.