Actor Model And Message Passing

What Message Passing Changes

Actor-style systems model concurrent work as isolated entities that receive messages, update private state, and send messages to other entities. The goal is not merely syntax; it is to reduce accidental shared mutable state and make communication explicit.

Erlang and Elixir make this model central through BEAM processes, mailboxes, links, monitors, and OTP supervision. Scala has actor libraries such as Akka. Go channels support message passing even though goroutines can also share memory.

Strengths

Message passing fits stateful services, realtime systems, protocol servers, queues, event processors, workflow coordinators, and systems where failure isolation matters. It can make ownership clearer because a process or actor owns its state and other code interacts through messages.

Supervision adds another layer: when an actor or process fails, a parent can restart it according to a defined strategy. That is why OTP-style systems are often discussed in terms of fault tolerance rather than only concurrency.

Watch Points

Message passing does not remove distributed-systems problems. Queues can grow, messages can arrive late or out of expected order, serialization can fail, backpressure must be designed, and state recovery needs persistence or replay strategy.

Actor systems also vary. Some are local runtime abstractions; others support distributed nodes. Do not assume location transparency, delivery guarantees, or restart behavior without checking the platform.

Related Concepts

Compare with Threads And Shared Memory, Goroutines And Green Threads, Data Races And Memory Models, and Structured Concurrency.