3 ms·

IDK how I typo'd OTC lol, sorry about that. What you're talking about is the fact that Erlang as a VM is well built. That is irrelevant to whether or not super

IDK how I typo'd OTC lol, sorry about that. What you're talking about is the fact that Erlang as a VM is well built. That is irrelevant to whether or not supervisory trees are equivalent to what an OS provides. > No operating system comes close to delivering that kind of reliability. Erlang runs on an OS though. Like, Erlang would inherently always be limited by the reliability of the underlying system and in fact relies entirely on it for preemption. > (one with which I strongly identify so forgive me the soapbox mode) For the record, I am an extreme fan of Joe's and I routinely re-read his thesis, so you are preaching to the choir in a way. > This is a completely different kettle of fish than stringing together a bunch of services using kernel or auxiliary mechanisms, both in terms of results and in terms of overhead. I just totally disagree and in fact you'll find that Erlang's seminal works used the term 'processes' and in fact is based on the entire model of OS processes. Off the top of my head he cites at least two papers about processes and transactions as the foundation for reliability in his thesis.

jacquesm 3y ago
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.
- insanitybit 3y ago
  > 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

jacquesm 3y ago

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.

insanitybit 3y ago
> 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