The point is scaling. Think in terms of request rate. If you know you can have millions of processes per machine and they run well in parallel, then you can handle requests with processes and stop worrying.
Scalability and large actor counts aren't the definitive features of Erlang, though. It's supervision trees, the distribution protocol, the OTP framework, the primacy of tuples and lists as your main and highly flexible data types, a great pattern matching engine for binary formats and regular Erlang terms alike, module-level hotswapping, a crash-only programming model, the ability to have external programs benefit from Erlang semantics via external nodes and ports, so on and so forth.
Yes, not all of this is thanks to the VM in of itself. A lot of it is runtime and language features.
But it's already there in a cohesive whole. There is absolutely no reason to switch to the JVM when the EVM is a beast of its own.
This is the language feature that `pron` keeps mentioning. Nothing about the VM is especially better for this than the JVM for instance.
> I see nothing wrong with ETS, it's well optimized for the Erlang term format in particular and gives you serializable updates.
There isn't anything wrong with it (as a complete neophyte to ETS and the EVM generally), the question is how much better it could be if it was on one of the several first rate JVMs that get so much more resources poured into them. Sharing data concurrently is precisely what the JVM is good at (especially at very large data set size). So in the cases where you need to use something like ETS, there is a lot of potential for improvement on a JVM vs EVM.
> But it's already there in a cohesive whole. There is absolutely no reason to switch to the JVM when the EVM is a beast of its own.
I don't want to speak for `pron` but I suspect what he is getting at is, the combination of the Erlang full story on the JVM would be a phenomenal bit of tech and it would be much easier (and more likely) for the Erlang bits to get ported to the JVM than it would be to bring the EVM up to the standard of any of the best JVMs.
I think there is, if you want to concentrate your limited resources on the language and its phenomenal libraries while letting an enormous team working on the world’s second-largest open-source project take care of the VM for you, while at the same time giving you better performance and a wider reach. There are many more organizations that would adopt Erlang if it were on the JVM.
In theory, yes. In practice, it's very difficult. JVM thread corresponds to a thread of host OS. Spawning and keeping those is very slow and expensive compared to Erlang's processes. You could have a pool of pre-spawned workers, but suddenly you can't spawn a worker for each connection and hope it will all work; you need to manage the pool. You also could try to implement green threads in JVM, as they are in Erlang, but you would need an entirely new compiler to insert yield points at appropriate places, or else you would get exactly the same problems with green threads as everywhere else.
Under JVM you just don't spawn a thread for each and every activity, because you would choke your system. The whole point of developing Erlang was to allow exactly this programming style in a manner safe against processing congestion.
I am talking about a new compiler. An Erlang compiler. The JVM is a virtual machine. Erlang is a language. We've already proven you can run Erlang on the JVM quite well, and that was before many pertinent improvements to the JVM and its ecosystem.
I think that's an interesting and useful comparison point to start with to test your claim. This is also something I figured Java side would greatly improve on.
