Is there any difference between "real OO" as described by Kay, and the "actor model"?

Seems like the same thing with a different name. But suppossedly the "actor" model lets youd eal with concurrency naturally. I don't buy it, since the real consistency problems arise on a higher abstraction level than the explicit code implementation.

I use the actor model in erlang and I really get concurrency for free. The only problem with "objects are just actors" is that if you do the blocking receive on a mailbox then you can't "call yourself" or a call chain can't call one of the callers since that's a deadlock.

Huh... is the difference here that something like Smalltalk uses some isolation in the form of the call stack, which makes some things easier (like recursion and some state kept on the stack) but also doesn't allow implicit concurrency or create the firmer boundaries of Actors? (I'm not sure, just trying to puzzle out the difference)

How about the classical "two clients read/write variables concurrently from your database". How does the actor model improves correctness over standard oop?

I just read the original 1973 Actor paper. The story is, in 1973 Alan Kay gave a talk to Carl Hewitt's group at Stanford about Kay's object-oriented model of computation. A few months later, Hewitt published the actor paper, which summarizes Kay's OO model, and describes the Actor model, which is an elaboration of the OO model that gives an explicit account of concurrency, and renames 'objects' to 'actors'. Kay's original OO model is pretty general, and doesn't specify how concurrency works. Actors is a more specific form of OO. Likewise, Smalltalk is an implementation of OO that makes some specific design decisions: message passing is synchronous, all objects are instances of classes, and there is single inheritance between classes. Actors supports asynchronous message passing, and supports delegation instead of class inheritance. The Actors paper says that everything is an actor: numbers are actors, lambda expressions are actors, etc. Recursive functions don't appear to be ruled out. AFAIK Erlang is a specific implementation of Actors that makes specific design decisions, although I don't use Erlang and don't understand the subtleties here.