4 ms·

Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. In earlier iterations (iirc) of the vm, the list length() function wa

Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. In earlier iterations (iirc) of the vm, the list length() function was very obnoxiously blocking and would not yield. Erlang doesn't enforce message passing. You can use ets tables to coordinate processes (but don't). A lot of pls claim erlang inspiration, e.g. pony, but miss some very important points and focus on "actors". Erlang isn't even really an actor system at heart, it just looks like it superficially. Actor systems at their core are message and coordination focused; when you write an erlang or elixir program you are typically minimizing the message passing because it is imperformant and hard to reason about. The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling (if x crashes also crash y, because now the state of y can't be trusted).

zelphirkalt 5y ago
However, by separating out into Erlang's lightweight processes using actors, you enable your code to make use of massive concurrency and thus of what Erlang is good at. From a certain level of concurrency onwards in a big enough problem to solve, the imperformance of message passing becomes less relevant in comparison to being able to process concurrently in many lightweight processes. So one could argue, that indeed some focus on actor systems is not entirely missing the point.
staticassertion 5y ago
> Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. At some level this is true of all systems - you can't yield in the middle of a `mov`, for example. But as Erlang is interpreted it doesn't rely on yield points. The caveat is that it does if you use CFFI. > You can use ets tables to coordinate processes (but don't). Yeah I'm sure there are endless ways to bypass the intended use of Erlang, I don't think it's really important. This is way different from Go where data is trivially shared across a channel. > The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling Yes, this is true. The foundation of Erlang is based on earlier research that Armstrong cites in his thesis paper, such as the persistent process and transaction as the basis of system resiliency. But it's not a coincidence he landed on actors to express those things.
- dnautics 5y ago
  Erlang is compiled to bytecode, and the yield points are between each instruction sort of. > The caveat is that it does if you use CFFI. No shit, I wrote a huge FFI library for the BEAM (that even implements a yielding system.that interops with erlang's yields), that's a huge part of my point about the beam not really being preemptive. > But it's not a coincidence he landed on actors to express those things. Yes, that's my point. In erlang the conceptual arrow goes (resiliency => not-really-but-kinda-like-actors). In these other systems, or at least the ones I've peeked at, like pony and bastion the logic goes (actors => underpants gnomes => something like erlang). It's completely backwards.
  - staticassertion 5y ago
    > Erlang is compiled to bytecode, and the yield points are between each instruction sort of. This is basically what I'm saying... at some point nothing is preemptive ie: at the instruction level. > that's a huge part of my point about the beam not really being preemptive. OK but I think that's really semantics, it doesn't really matter though. You are right that BEAM can't yield within an instruction or during FFI. If you think that means it isn't preemptive, ok, but as I said I think at some point you end up with "nothing is preemptive" and then "why do we have the word preemptive" and then "because it's useful to describe systems like BEAM". > Yes, that's my point. In erlang the conceptual arrow goes (resiliency => not-really-but-kinda-like-actors). In these other systems, or at least the ones I've peeked at, like pony and bastion the logic goes (actors => underpants gnomes => something like erlang). It's completely backwards. Sure, actors aren't "the point". They just satisfy important properties that are necessary for resiliency. Pony takes a very very different approach from Erlang. Bastion seems closer. I don't think "distance from Erlang" is really important or interesting though. Inspiration from Erlang is present in many of these systems, whether they re-implement the exact concepts or not.

zelphirkalt 5y ago

However, by separating out into Erlang's lightweight processes using actors, you enable your code to make use of massive concurrency and thus of what Erlang is good at. From a certain level of concurrency onwards in a big enough problem to solve, the imperformance of message passing becomes less relevant in comparison to being able to process concurrently in many lightweight processes. So one could argue, that indeed some focus on actor systems is not entirely missing the point.

staticassertion 5y ago

> Honestly erlang isn't really preemptive either, it just has a lot of hidden yield points. At some level this is true of all systems - you can't yield in the middle of a `mov`, for example. But as Erlang is interpreted it doesn't rely on yield points. The caveat is that it does if you use CFFI. > You can use ets tables to coordinate processes (but don't). Yeah I'm sure there are endless ways to bypass the intended use of Erlang, I don't think it's really important. This is way different from Go where data is trivially shared across a channel. > The raison d'etre of erlang processes is not really message passing concurrency, it's failure domain definition and failure domain bundling Yes, this is true. The foundation of Erlang is based on earlier research that Armstrong cites in his thesis paper, such as the persistent process and transaction as the basis of system resiliency. But it's not a coincidence he landed on actors to express those things.

dnautics 5y ago
Erlang is compiled to bytecode, and the yield points are between each instruction sort of. > The caveat is that it does if you use CFFI. No shit, I wrote a huge FFI library for the BEAM (that even implements a yielding system.that interops with erlang's yields), that's a huge part of my point about the beam not really being preemptive. > But it's not a coincidence he landed on actors to express those things. Yes, that's my point. In erlang the conceptual arrow goes (resiliency => not-really-but-kinda-like-actors). In these other systems, or at least the ones I've peeked at, like pony and bastion the logic goes (actors => underpants gnomes => something like erlang). It's completely backwards.
- staticassertion 5y ago
  > Erlang is compiled to bytecode, and the yield points are between each instruction sort of. This is basically what I'm saying... at some point nothing is preemptive ie: at the instruction level. > that's a huge part of my point about the beam not really being preemptive. OK but I think that's really semantics, it doesn't really matter though. You are right that BEAM can't yield within an instruction or during FFI. If you think that means it isn't preemptive, ok, but as I said I think at some point you end up with "nothing is preemptive" and then "why do we have the word preemptive" and then "because it's useful to describe systems like BEAM". > Yes, that's my point. In erlang the conceptual arrow goes (resiliency => not-really-but-kinda-like-actors). In these other systems, or at least the ones I've peeked at, like pony and bastion the logic goes (actors => underpants gnomes => something like erlang). It's completely backwards. Sure, actors aren't "the point". They just satisfy important properties that are necessary for resiliency. Pony takes a very very different approach from Erlang. Bastion seems closer. I don't think "distance from Erlang" is really important or interesting though. Inspiration from Erlang is present in many of these systems, whether they re-implement the exact concepts or not.