3 ms·

> The big problem nobody talks about with actors and message passing is non-determinism and state. Seems to be mentioned in the article, with an example: > If

> The big problem nobody talks about with actors and message passing is non-determinism and state. Seems to be mentioned in the article, with an example: > If more than one process sends signals to a common process, they can arrive in any order even when you “know” that one of the signals was sent first.

chrisseaton 6y ago
Right - that's what triggered my comment - but I think it's a bigger footgun than the article does. The problem is this corner case opens up all the fundamental issues I mention. When we include it we've got a big non-deterministic, racey, stateful, problem.
- jerf 6y ago
  In practice, I don't think it is for real Erlang programs. If you need total order, route everything that needs that order through one process, and you have it. For instance, you can use that to impose total order on messages in a chat room. As long as "one chat room" is small enough for that to be practical even at your largest size, it works. If that doesn't work, don't use Erlang. No sarcasm. The process model is nice but does preclude certain high-performance patterns.
- uwiger 6y ago
  Experience shows that it really isn't. The fundamental issues of non-deterministic ordering are inherent in the domain that Erlang was designed for, and the VM characteristics pretty closely reflect that. It turns out that people have comfortably written complex and scalable commercial systems in Erlang for decades, and many have noted that for people who understand the problem domain, the Erlang model feels intuitive. The problem of message order non-determinisim is real, but for orchestration logic in scenarios with multiple uncoordinated message sources, it's inescapable. What is important is that the programming environment helps you deal with it, and doesn't introduce additional - "accidental" - complexity. I discussed this topic at QCon 2010, and ran through some demos to illustrate where many commercial projects actually DO go wrong, and why the textbook Erlang model keeps you safe. https://www.infoq.com/presentations/Death-by-Accidental-Complexity/ https://www.infoq.com/presentations/Death-by-Accidental-Comp... The key guarantees that Erlang gives you here are: * Messages from A to B will all arrive (if they arrive) in the order in which they were sent, and you can detect if there is an interruption * A receiving process can decide in which order messages are processed. It turns out that people intuitively understand that if Alice and Bob each send me a message, independently of each other, I cannot know which message reaches me first. This mirrors a fundamental real-world constraint, and in a distributed processing environment, there really isn't much you can do about it. There are other concurrency-related problem domains, some for which the Erlang implementation, at least, is not ideal.

chrisseaton 6y ago

Right - that's what triggered my comment - but I think it's a bigger footgun than the article does. The problem is this corner case opens up all the fundamental issues I mention. When we include it we've got a big non-deterministic, racey, stateful, problem.

jerf 6y ago
In practice, I don't think it is for real Erlang programs. If you need total order, route everything that needs that order through one process, and you have it. For instance, you can use that to impose total order on messages in a chat room. As long as "one chat room" is small enough for that to be practical even at your largest size, it works. If that doesn't work, don't use Erlang. No sarcasm. The process model is nice but does preclude certain high-performance patterns.
uwiger 6y ago
Experience shows that it really isn't. The fundamental issues of non-deterministic ordering are inherent in the domain that Erlang was designed for, and the VM characteristics pretty closely reflect that. It turns out that people have comfortably written complex and scalable commercial systems in Erlang for decades, and many have noted that for people who understand the problem domain, the Erlang model feels intuitive. The problem of message order non-determinisim is real, but for orchestration logic in scenarios with multiple uncoordinated message sources, it's inescapable. What is important is that the programming environment helps you deal with it, and doesn't introduce additional - "accidental" - complexity. I discussed this topic at QCon 2010, and ran through some demos to illustrate where many commercial projects actually DO go wrong, and why the textbook Erlang model keeps you safe. https://www.infoq.com/presentations/Death-by-Accidental-Complexity/ https://www.infoq.com/presentations/Death-by-Accidental-Comp... The key guarantees that Erlang gives you here are: * Messages from A to B will all arrive (if they arrive) in the order in which they were sent, and you can detect if there is an interruption * A receiving process can decide in which order messages are processed. It turns out that people intuitively understand that if Alice and Bob each send me a message, independently of each other, I cannot know which message reaches me first. This mirrors a fundamental real-world constraint, and in a distributed processing environment, there really isn't much you can do about it. There are other concurrency-related problem domains, some for which the Erlang implementation, at least, is not ideal.