[AlexanderDhoore]

The whole error handling philosophy of Erlang is extremely fascinating. The fact that it was born out of the telecommunication world makes it extremely fit for this kind of job. I've been reading "Programming Erlang" on and off for a few weeks now, and it's... eye opening. Erlang proves functional programming is for the real, real world. There isn't a language that's more down to earth, ready to "Get Shit Done" than Erlang.

Edit: When you learn Erlang you'll notice every design decision was made for performance or reliability (vs making the language "nice", think Ruby). I appreciate that.

[Glide]

I think the golden moment for me thinking about Erlang was when I started thinking that the actor model was made to support fault tolerance and concurrency was a nice bonus.

[derefr]

Indeed, for all the free wins you get from Erlang's actor model (e.g. easy just-add-cores parallelism), you also get losses (e.g. copy-based message-passing is pretty much the least performant signalling mechanism possible.) But when you look at it all through the lens of fault-tolerance, there's really nothing you can change about Erlang's semantics without throwing away some guarantee or another.

When I hear that other languages (e.g. Go) have "actors like Erlang", I have to laugh. Unless you're willing to eat all the disadvantages and performance losses that come with Erlang's approach, you don't really have "actors like Erlang"; you just have green threads.

[wcummings]

It's downright adorable when people compare a half-baked language like Go to Erlang/OTP

[rdtsc]

Yeah Joe makes that point pretty often, and it was a nice revelation for me as well.

Actor concurrency paradigm has been copies by other languages and libraries. Not many managed to copy the fault tolerance and transparent distribution aspect. Granted there are other ways to solve that (OS processes, VMs) but still, it is interesting to learn from and think about.