[troupo]

Erlang's concurrency story isn't green threads.

It's (with caveats, of course):

- a thread crashing will not bring the system down

- a thread cannot hog all processing time as the system ensures all threads get to run. The entire system is re-entrant and execution of each thread can be suspended to let other threads continue

- all CPU cores can and will be utilized transparently to the user

- you can monitor a thread and if it crashes you're guaranteed to receive info on why and how it crashed

- immutable data structures play a huge part of it, of course, but the above is probably more important

That's why Go's concurrency is not that good, actually. Goroutines are not even half-way there: an error in a goroutine can panic-kill your entire program, there are no good ways to monitor them etc.

[kbolino]

Neither an error nor a recovered-from panic will cause a Go program to crash; only an unrecovered panic does that.

The bigger problem with Go in this regard is how easy it is to cause a panic thanks to nil.

[troupo]

In Erlang even a nil will not lead to an unrecovered panic (if it happens in the process aka green thread).

Go made half a step in the right direction with goroutines, but never committed fully

[kbolino]

Each has its tradeoffs. I had a case that cropped up more than once where RabbitMQ kept on trucking even though the process for an important queue had crashed; had it propagated all the way to the server itself it may have been easier to diagnose and fix (I'm assuming there's something like defer or finally in Erlang to ensure the mnesia database was synced properly on exit). Instead, I had to monitor for this condition and periodically run some command-line trickery to fix it (without ever really knowing why it happened). This was years ago, maybe RabbitMQ handles that better now.

The Go authors are adamant that goroutines not be addressable (from without) or identifiable (from within). This is diametrically opposed to Erlang, where processes are meant to be addressed/identified. I can't say I've ever found a case where a problem couldn't be solved due to this constraint in Go, but it does complicate some things.