Will the next WhatsApp be written in Java?
For one, the Erlang VM has built-in preemptive green thread scheduling, which means it can suspend your green thread at ANY instruction, not just when an IO call is in progress.
Loom is a step in the right direction, but Erlang is in its own universe for what it was designed for.
True. Out of curiosity: what's the use case for this?
Surely side-effects-out-of-your-system is enough?
Scheduling is deterministic, which is a VERY useful property to have. See ex. http://erlang.org/pipermail/erlang-questions/2006-December/0... about changing scheduler determinism.
Here is a simple echo server running on Virtual thread (using same old blocking APIs, handle 5m persistent connections) - https://github.com/ebarlas/project-loom-c5m/blob/main/src/ma...
Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?
A benchmark should settle things in that case. Maybe it will be a draw! Erlang's almost-no-op deallocation vs Java's world-class JIT. Some applications are bound to be better suited to one specific side. I guess we'll see; but it cannot be denied that with Loom Java started to compete on a non-void part of Erlang's land.
That comes at some extreme costs and implications to what the VM is capable of achieving, but it is something that's pretty impressive.
