3 ms·

Mutable state is essential to the actor model. Local arguments to a tail-recursive message loop which change based on the last received message and the previous

Mutable state is essential to the actor model. Local arguments to a tail-recursive message loop which change based on the last received message and the previous arguments, and determine behavior (i.e. messages sent and side effects), are equivalent to local mutable state. State machines are a lot better than unstructured, freely mutable global variables, but they are still mutable state.

pdimitar 6y ago
Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.
- eru 6y ago
  No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user. It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described. (And I liked programming in Erlang.)
  - pdimitar 6y ago
    And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you give a few examples. I was under the impression that my parent poster made the point of "but your FP code gets compiled to imperative mutable code so FP is not good" or something. If I was mistaken in my interpretation then we're talking past each other.
    - eru 6y ago
      As far as I can tell, that's not what the great-grand parent comment was about. Have you ever programmed in Erlang? About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)
      - pdimitar 6y ago
        I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.
        TeMPOraL 6y ago
        I understand the point as: being able to send a message to a particular actor, passing it a value that you can later retrieve by sending that same actor another message, is semantically exactly the same as calling a setter on an object reference, and later calling a getter to get the value back. In both cases you have a pocket of mutable state, potentially accessible by multiple unrelated places in code, that isn't reflected in function signatures.
        pdimitar 6y ago
        Mostly true, minus the fact that the mutable state's access is serialized / centralized due to the nature of Erlang's actors (lightweight threads; usually called fibers in other languages, and even that is not a good analogy since they are preemptive and not cooperative). So the semantics being similar is not strictly and 100% true. You can't do non-atomic volatile modification like you can in C/C++.
        eru 6y ago
        > You can't do non-atomic volatile modification like you can in C/C++. Yes, exactly. No one was implying that Erlang's model is mimicking those particularly weird languages. The statement was much more narrow.
deleted 6y ago
[deleted]

pdimitar 6y ago

Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.

eru 6y ago
No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user. It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described. (And I liked programming in Erlang.)
- pdimitar 6y ago
  And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects. But maybe we'll talk the same language if you give a few examples. I was under the impression that my parent poster made the point of "but your FP code gets compiled to imperative mutable code so FP is not good" or something. If I was mistaken in my interpretation then we're talking past each other.
  - eru 6y ago
    As far as I can tell, that's not what the great-grand parent comment was about. Have you ever programmed in Erlang? About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)
    - pdimitar 6y ago
      I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.
      - TeMPOraL 6y ago
        I understand the point as: being able to send a message to a particular actor, passing it a value that you can later retrieve by sending that same actor another message, is semantically exactly the same as calling a setter on an object reference, and later calling a getter to get the value back. In both cases you have a pocket of mutable state, potentially accessible by multiple unrelated places in code, that isn't reflected in function signatures.
        pdimitar 6y ago
        Mostly true, minus the fact that the mutable state's access is serialized / centralized due to the nature of Erlang's actors (lightweight threads; usually called fibers in other languages, and even that is not a good analogy since they are preemptive and not cooperative). So the semantics being similar is not strictly and 100% true. You can't do non-atomic volatile modification like you can in C/C++.
        eru 6y ago
        > You can't do non-atomic volatile modification like you can in C/C++. Yes, exactly. No one was implying that Erlang's model is mimicking those particularly weird languages. The statement was much more narrow.

deleted 6y ago

[deleted]