Hacker News Reader

Comment by toast0 | Hacker News Reader

As an Erlang person, from reading about Java's Virtual Threads, it feels like it should get a significant portion of the Erlang concurrency story.

With virtual threads, it seems like if you don't hit gotchas, you can spawn a thead, and run straight through blocking code and not worry about too many threads, etc. So you could do thread per connection/user chat servers and http servers and what not.

Yes, it's still shared memory, so you can miss out on the simplifying effect of explicit communication instead of shared memory communication and how that makes it easy to work with remote and local communication partners. But you can build a mailbox system if you want (it's not going to be as nice as built in one, of course). I'm not sure if Java virtual threads can kill each other effectively, either.

View on HN

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.

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.

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

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.

Reply on news.ycombinator.com