[tokenrove]

I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.

[pron]

Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job done for whatever it is they're used for, and if all you're doing is IO it may not be too bad, but let's not mention those runtimes anywhere near good performance. BEAM is certainly in the bottom half or third of the Techempower benchmarks.

[verttii]

yeah each individual process has low resource allocation. There could be millions running on the same box so that makes sense.

Luckily, computational parallelization is not a big challenge with new libraries such as: https://github.com/plataformatec/flow

However, immutability might still become a challenge in terms of resources/performance. Rust is often used to patch that with Erlang's NIF.

[cutler]

Don't forget Fibers - coming to a JVM near you soon!

[Blackthorn]

Hard for him to forget that -- take a look at who you're responding to.