Yes, but those processes are much lighter weight than OS processes and can be created and destroyed in a very small fraction of the time that the OS does the same thing.
> Like, Erlang would inherently always be limited by the reliability of the underlying system and in fact relies entirely on it for preemption.
This is factually incorrect, sorry. The Erlang VM uses something called 'reductions' which preempt Erlang processes when their computational slice has been reached which has absolutely nothing to do with the OS preemption mechanism.
And an Erlang system can span multiple machines with ease, even if those machines are located in different physical locations.
Erlang processes are more along the lines of greenthreads than full OS processes but they do not use the 'threads' mechanism the OS provides for the basic scheduling. The VM does use OS threads but this is mostly to decouple IO from the rest of the processing.
Oh, and BEAM/Erlang can run on bare metal if it has to.
> Yes, but those processes are much lighter weight than OS processes and can be created and destroyed in a very small fraction of the time that the OS does the same thing.
Yes, that is true. I don't think that is relevant to the semantics of the constructs.
> The Erlang VM uses something called 'reductions' which preempt Erlang processes when their computational slice has been reached which has absolutely nothing to do with the OS preemption mechanism.
That preemption relies on the runtime yielding at every function call. The only thing that can actually preempt a process mid instruction is the kernel, and actually it can't do that either it's the hardware that yields to the kernel.
> And an Erlang system can span multiple machines with ease, even if those machines are located in different physical locations.
Yes, that's not unique to Erlang, obviously one can launch processes on arbitrary machines.
> Erlang processes are more along the lines of greenthreads than full OS processes but they do not use the 'threads' mechanism the OS provides for the basic scheduling.
I think you're getting hung up on implementation details. The abstraction is semantically equivalent. One might be faster, one might be heavier, one might have some nice APIs, but in terms of supervisory primitives, as I said before, the only thing required is `link` and processes have that.
I'm too lazy to go to the various paper Joe cites but if you take the time you'll find that many of them are about processes
> Like, Erlang would inherently always be limited by the reliability of the underlying system and in fact relies entirely on it for preemption.
This is factually incorrect, sorry. The Erlang VM uses something called 'reductions' which preempt Erlang processes when their computational slice has been reached which has absolutely nothing to do with the OS preemption mechanism.
And an Erlang system can span multiple machines with ease, even if those machines are located in different physical locations.
Erlang processes are more along the lines of greenthreads than full OS processes but they do not use the 'threads' mechanism the OS provides for the basic scheduling. The VM does use OS threads but this is mostly to decouple IO from the rest of the processing.
Oh, and BEAM/Erlang can run on bare metal if it has to.