[eru]

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]

I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.

[TeMPOraL]

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]

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]

> 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.