4 ms·

No but also key to the definition of the actor system is that those are the only things they are allowed to do. Also, there's strange stuff like naming process

No but also key to the definition of the actor system is that those are the only things they are allowed to do. Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs. Point is all of these deviations from actor system were choices made by the Erlang team in the name of pragmatism. They all exist because there was a use case and the first teams using Erlang needed them for something real; that Erlang is not an actor system is important, because it's a highly pragmatic system -- not one that is based in theory.

toast0 5y ago
> Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs. Ets tables are observationally equivalent to an Erlang process per table and sending it a message for each function call. It's not actually implemented that way, but I don't think that is grounds to disqualify it. I don't remember enough details about the naming process, but I think that might be similar; you could send a message to a naming process to set and lookup the names (although you'd have a bit of trouble finding out what the process id of the naming process is, wouldn't you?), it's just not very pragmatic. Nifs certainly have the potential to break the model of course. I'd think selective receive should be fine too, it's equivalent to reading (or peeking) and saving messages until a matching message is received, processing that message, then processing future messages from the saved queue. It's just implemented in a more pragmatic way. If immutability is important, then the process dictionary means Erlang doesn't qualify, but again, it's pragmatic. I'd rather have a pragmatic almost actor system than a dogmatic Actor system that's hard to use.

toast0 5y ago

> Also, there's strange stuff like naming processes for service discovery, and iirc something is wrong with the way that Erlang does selective receives that disqualifies it from being an actor system, and ultimately more modern Erlang things like ets tables and sharing memory with nifs. Ets tables are observationally equivalent to an Erlang process per table and sending it a message for each function call. It's not actually implemented that way, but I don't think that is grounds to disqualify it. I don't remember enough details about the naming process, but I think that might be similar; you could send a message to a naming process to set and lookup the names (although you'd have a bit of trouble finding out what the process id of the naming process is, wouldn't you?), it's just not very pragmatic. Nifs certainly have the potential to break the model of course. I'd think selective receive should be fine too, it's equivalent to reading (or peeking) and saving messages until a matching message is received, processing that message, then processing future messages from the saved queue. It's just implemented in a more pragmatic way. If immutability is important, then the process dictionary means Erlang doesn't qualify, but again, it's pragmatic. I'd rather have a pragmatic almost actor system than a dogmatic Actor system that's hard to use.