To some approximation. The Actor Model formalism [0] requires certain properties, notably: 1. Communication solely by asynchronous message passing 2. A mailb

To some approximation. The Actor Model formalism [0] requires certain properties, notably: 1. Communication solely by asynchronous message passing 2. A mailbox per actor that means the reception of messages and the processing of them is decoupled (i.e. an actor can receive new messages even when processing a previously-received message). The OO model in general supports that paradigm. Pretty much all mainstream OO languages are synchronous by default though. Call a method and the caller is suspended until the method returns. Multiple clients can call methods on the same object concurrently, but doing that safely requires some form of locking/protection to be implemented in the target object. Stated alternatively: threads in mainstream OO languages run "across" objects, whereas each actor has its own thread in the Actor model. There are certainly similarities - in the sense that both actors and objects encapsulate state, with reading/writing occurring through well-defined interfaces (messages and methods respectively). But the threading model is quite different - it's not just a matter of scale. [0] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model EDIT: corrected grammar & formatting.