Actor messages
Each actor has its own mailbox and handles one message at a time; it sends messages without waiting and gets results back as more messages.
How they work
Carl Hewitt’s 1973 actor formalism built everything from one kind of behaviour: sending messages to actors. In Erlang every process has its own queue of incoming messages, and receive takes the first one that matches a pattern. Processes share no data, which is why Erlang calls them processes rather than threads.
Sending doesn’t hand over the caller’s thread, so the sender carries on, and a result comes back as a reply message rather than a return value. Because each actor handles at most one message at a time, its state needs no locks; the Akka docs describe millions of actors scheduled on a dozen threads.
With no shared call stack between sender and receiver, a failure can’t be thrown back to the caller. Actor systems handle it with supervision instead: in Erlang/OTP, supervisor processes monitor workers and restart them when something goes wrong. The actors concept covers placing actors across a cluster.
Sources
- Hewitt, Bishop and Steiger: A Universal Modular ACTOR Formalism for Artificial Intelligence (IJCAI 1973)
- Erlang/OTP docs: Concurrent programming (processes share no data; each has its own message queue)
- Akka docs: How the actor model meets the needs of modern, distributed systems (mailboxes, one message at a time, no shared call stack)
- Erlang/OTP docs: Design principles (supervisors monitor and restart workers)