3 ms·

Immutability is part of what leads to it being easy to program, as well. An actor in a given state, receiving a given kind of message, will always behave the sa

Immutability is part of what leads to it being easy to program, as well. An actor in a given state, receiving a given kind of message, will always behave the same way (barring some abuse of ETS tables or the process dictionary or other bad practices). Meaning that to reason about the code I usually don't need to -care- about the chain of causality. I can break each part of my complex interaction into a series of "message received -> actor does something -> message sent", and trace through the code that way, turning what would be a big complex hairy problem of mutable state and race conditions in many other languages into a fairly innocuous, straightforward series of small, simple interactions.

platz 11y ago
Yes, as I said, each individual piece (actor) is easy to understand, locally. But you cannot in general understand the global behavior of the system that way. One option might be to run an integration test, for example, but understanding why a certain actor recieved a given message will be difficult.
- lostcolony 11y ago
  And what I was saying is that in an immutable system, that's -usually enough-. It's not that difficult, because the reasons for messages being sent are predictable. You get a lot of emergent behavior in systems with mutable state that is avoided in systems that enforce immutable state, and without that it becomes far more tractable to trace back a series of events and reason about them. You got a message? Okay, who can send that message? If it's more than one, is there a reason why you aren't indicating -who- sent that message (in Erlang, including a pid as part of the message; this is done automatically any time you use a gen_server and send a synchronous message via call)? But regardless, what does that message mean? Is it the same across all senders? Because if so, your bug is in the implementation in this actor. If not, if the message means different things when sent from different places, you need to figure out what the different messages you want to send are, and send different messages for them. If you have mutable code, even mutable message passing, the time the message arrived changes what it does. Suddenly you have situations where the message being sent, and the behavior the actor exhibits, is dependent on mutable state. It's totally correct in some instances, and totally incorrect in others; completely dependent on what has happened in the system previously as to whether ~this~ particular message, with the coded behavior, does the right thing or not. And it's that, the interplay of all events that came before, that makes things complex.
  - platz 11y ago
    Yeah, I can see how adhering to nice principles leads to more predictable behavior in erlang. And clearly people do it which seems to back up the claim.

platz 11y ago

Yes, as I said, each individual piece (actor) is easy to understand, locally. But you cannot in general understand the global behavior of the system that way. One option might be to run an integration test, for example, but understanding why a certain actor recieved a given message will be difficult.

lostcolony 11y ago
And what I was saying is that in an immutable system, that's -usually enough-. It's not that difficult, because the reasons for messages being sent are predictable. You get a lot of emergent behavior in systems with mutable state that is avoided in systems that enforce immutable state, and without that it becomes far more tractable to trace back a series of events and reason about them. You got a message? Okay, who can send that message? If it's more than one, is there a reason why you aren't indicating -who- sent that message (in Erlang, including a pid as part of the message; this is done automatically any time you use a gen_server and send a synchronous message via call)? But regardless, what does that message mean? Is it the same across all senders? Because if so, your bug is in the implementation in this actor. If not, if the message means different things when sent from different places, you need to figure out what the different messages you want to send are, and send different messages for them. If you have mutable code, even mutable message passing, the time the message arrived changes what it does. Suddenly you have situations where the message being sent, and the behavior the actor exhibits, is dependent on mutable state. It's totally correct in some instances, and totally incorrect in others; completely dependent on what has happened in the system previously as to whether ~this~ particular message, with the coded behavior, does the right thing or not. And it's that, the interplay of all events that came before, that makes things complex.
- platz 11y ago
  Yeah, I can see how adhering to nice principles leads to more predictable behavior in erlang. And clearly people do it which seems to back up the claim.