Since I am not familiar enough with Erlang to know, is that actually the same as concurrent code? I can certainly see how it would share many of the same logical issues, but does sharing an actor imply that you can have non-atomic operations on the actor, like inconsistent writes and reads? I was under the impression that it would at least be atomic because actors are single-threaded. It even guarantees message ordering, while memory does not in some widely used hardware architectures.

You can of course rebuild data races inside Erlang with the right set of messages, but it's not surprising that you can emulate a Turing-complete computer in a Turing-complete language.

> a thread-safe queue with pairwise ordering guarantees so that all processing on a particular actor's state is effectively atomic

> The big win for the actor model is (just) that it linearizes all operations on a particular substate of the program while allowing other actors' states to be operated on concurrently.

Came here to say exactly those two things. Your comment is as clear as it could be.