[hackyhacky]

> You wouldn't implement the "plus 2" program in an actor system this way, because of race conditions.

Can you explain how a serially-executed "increment" message in an actor system, as I've described above, would cause a race condition?

In an OOP system you could do the same, you'd just have to build the thread-safe message queue yourself. In actor languages it's built in.

There are cases where you can get race conditions in actor languages, but I'm pretty sure this isn't one.

[layer8]

The point is that you have to implement it in the specific ways you describe in order to prevent a race condition. The actor model doesn’t eliminate race conditions by itself. This is true in all programming models. A database also doesn’t eliminate race conditions, you have to use appropriate transactions in order to prevent them. What you describe for the actor model is virtually the same thing: you have to use transactional messages in order to prevent race conditions. And that doesn’t happen by itself, the programmer has to implement the program logic in that specific way. There is no magic silver bullet.

[hackyhacky]

> There is no magic silver bullet.

Did someone claim otherwise?

> The actor model doesn’t eliminate race conditions by itself.

Sure, and the actor model was never marketed as "a tool to eliminate race conditions." That's not what it's for.

You have to use your tools correctly. One benefit of the actor model is that the tool eliminates large categories of race conditions (but not all of them). One benefit of garbage collection is that the tool eliminates large categories of memory errors (but not all of them). The same can be said of anything, from high-level languages, to debuggers, to linters, the IDEs, etc. Just because a tool is not a "silver bullet" does not mean that it does not deliver a strong advantage for the programmer.