Actor Model Primer

The actor model treats each unit of state as an isolated process with a private mailbox. Actors do not share memory; they communicate by passing immutable messages. This single constraint eliminates most classes of race condition and turns concurrency from a footgun into a design primitive. Meridian uses an actor-style runtime under the hood, so understanding the basics pays off quickly when you start composing agents.

1. Actors, mailboxes, and isolation

An actor owns three things: a private state, a mailbox, and a behavior function. The runtime delivers messages to the mailbox one at a time. The behavior decides how to respond, what next state to become, and which other actors to spawn or notify. Because state is private, no lock is needed; the mailbox itself serializes access.

2. Supervision and failure

Actors are cheap, so the right reaction to a bad message is often to crash and let a supervisor restart a fresh actor with a clean state. This "let it crash" ethos pushes error handling out of the hot path and into a tree of supervisors, where escalation policies are explicit and easy to audit.

3. Location transparency

From the caller's perspective, sending a message to an actor on the same core looks identical to sending one across a network. The runtime can move actors between threads, processes, or machines without changing the calling code. That property is what makes the model scale from a single laptop to a fleet of nodes.

actor Counter {
  state count = 0

  on message Increment(n) {
    count = count + n
  }

  on message Read(replyTo) {
    replyTo.send(Value(count))
  }
}

let c = spawn Counter
c.send(Increment(1))
c.send(Increment(2))
c.send(Read(self))

Once these three ideas click, the rest of the literature (Erlang/OTP, Akka, Pony, Orleans) reads like dialects of the same language. Start with isolation, add supervision, finish with location transparency.