Carl Hewitt and the Actor Model: Computation Through Message-Passing Entities
The actor model reframed concurrent computation around independent entities that receive messages, change behavior and send messages rather than sharing one call stack.
The actor model began as a different way to describe computation
In the early 1970s, Carl Hewitt and collaborators were exploring programming models for artificial intelligence, parallel activity, and modular procedural knowledge. Their actor work did not begin as a cloud-computing framework. It grew from an attempt to describe active computational entities that respond to messages and can create further activity.[1][2]
That origin matters because the actor model is often retroactively described only as a technique for distributed services. Its historical roots are broader: programming-language semantics, artificial intelligence, modularity, and concurrency were intertwined.
The 1973 formalism made actors the central computational object
Hewitt, Peter Bishop, and Richard Steiger’s 1973 IJCAI paper proposed a modular ACTOR architecture conceptually based on one kind of object: actors. The paper treated sending messages to actors as a foundational behavioral mechanism.[1]
In the same period, the POPL paper on actor induction and meta-evaluation described an actor as an active agent that plays a role in response to a cue, using the metaphor to unify procedural behavior.[2]
Actors are not just ordinary objects with threads
The crucial abstraction is behavioral and communicative. An actor receives a message, can decide what to do next, can send messages, and can participate in further computation without requiring callers to share its internal mutable representation.
Message passing changed the boundary of encapsulation
Shared-memory concurrency exposes one memory space to multiple activities and then needs rules about who may touch what. The actor approach instead emphasizes communication through messages. Internal state can remain private to the actor’s behavior while interaction happens at an explicit boundary.[3]
This does not make races or ordering questions disappear; they move to message protocols, mailboxes, delivery assumptions, and actor lifecycles. But the unit of reasoning is different from a set of threads directly mutating the same object.
Actor semantics separated behavior from physical execution
The early actor literature emphasized that the abstraction need not reveal whether an implementation uses a particular data structure, processor, or low-level representation. That separation allowed the model to speak about many activities without requiring one operating-system thread per actor.[1]
Gul Agha’s 1986 treatment formalized Hewitt’s actor paradigm for concurrent and distributed computation, helping turn the earlier research program into a more mature model for analyzing large-scale parallel systems.[4]
Logical actors can outnumber processors
An actor is a unit in the computation model, not a promise of dedicated hardware. A runtime can multiplex many actors over fewer threads or processors, which is one reason the abstraction scales conceptually beyond the machinery available to a single process.
Asynchrony made control flow less like an ordinary call stack
When one procedure calls another synchronously, the caller normally waits for a return on the same logical control path. Actor messaging can decouple those paths. A sender can issue a message and continue, while a later message represents a result or another state transition.
This style fits systems where latency and partial failure make a global call stack misleading. It also requires programmers to model protocols explicitly because there may be no immediate return value tying cause and response together.
Actor research developed its own synchronization questions
Early work did not pretend that message passing eliminated synchronization. Actor semantics had to define how behavior changes, messages are processed, and concurrent actions interact. Greif and Hewitt’s 1975 work on PLANNER-73 used actors to discuss side effects, parallelism, and synchronization directly.[3]
The model therefore belongs in concurrency history not because it escapes coordination, but because it relocates coordination into message-driven behavior and identity.
Ordering assumptions must be stated, not imagined
Different actor systems can provide different guarantees about mailbox order, delivery, persistence, and failure. Historical precision requires distinguishing the abstract actor idea from the stronger guarantees supplied by a particular runtime.
Virtual actors adapted the model to cloud service lifecycles
Microsoft Research’s Orleans project introduced virtual actors for distributed interactive services. Its runtime manages activation, placement, and resource concerns so developers can program stateful entities without manually controlling every actor’s physical lifetime.[5]
This is not the same system Hewitt proposed in 1973. It is evidence of the model’s adaptability: the actor boundary can be preserved while runtimes take on more responsibility for distribution and availability.
The model became infrastructure rather than only theory
Modern actor frameworks use mailboxes, supervision, remote messaging, persistence, or virtual activation in different combinations. The persistence of the vocabulary shows that the original abstraction continued to offer a useful way to separate stateful behavior from the mechanisms executing it.
Why the actor model belongs in the history of parallel software
The actor model offered an alternative to coordinating shared mutable memory with locks. Hewitt and collaborators centered computation on independent active entities and messages; Agha later gave the paradigm a systematic concurrent and distributed treatment; newer systems adapted it to cloud-scale services.[1][4][5]
It should not be collapsed into every system that happens to use queues or agents. Its historical importance is more specific: it made asynchronous message-driven entities a first-class model of computation.
Works Cited
- 01
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead