Actors vs CSP

The 30-second version

When several tasks run at the same time, the dangerous thing is a variable that more than one of them can change. Two tasks update it at once, and one update silently disappears (§02 shows exactly how). Two well-known approaches — actors and CSP — both start from one idea: don't share the variable at all; send messages instead.

The map of this page

• §02–§04 (level 1): the problem, the actor model, and how it differs from channels — with three things to click.
• §05–§07 (level 2): build an actor in Go and in JavaScript, then see what Erlang and Akka add: supervisors that restart crashed actors.
• §08–§10: what goes wrong in production (overflowing mailboxes, message order, deadlocks), and how to choose.
• §11–§12: quiz and cheat sheet.

The problem: two writers, one variable

Take a bank account with 100 in it. Two goroutines each deposit 50 at the same moment. You expect 200. The trouble is that balance += 50 isn't one step for the computer — it's three: read the balance, add 50, write the result back. If both goroutines read before either one writes, both write 150, and one deposit vanishes.

Step through it, then flip the toggle to see the same job done by a single owner:

1balance := 100
2 
3deposit := func() {   // "balance += 50", spelled out
4    tmp := balance    // 1. read
5    tmp = tmp + 50    // 2. add
6    balance = tmp     // 3. write back
7}
8go deposit()          // goroutine A
9go deposit()          // goroutine B

When two goroutines touch the same variable at the same time, at least one writes, and nothing coordinates them, it's called a Data raceData raceTwo threads or goroutines access the same memory, at least one of them writes, and nothing orders the two accesses (no lock, channel or atomic between them). The result is unpredictable.. Go even ships a tool to catch it: run your tests with go test -race.

Three ways out

A LockLock (mutex)A “do not disturb” sign for a piece of data: only the task holding the lock may touch it; others wait their turn. keeps the data where it is and makes tasks queue up for it. The other two are both message passing: instead of reaching into shared memory, tasks send each other values. This page is about those two, and how they differ.

The actor model: people with inboxes

The idea comes from Carl Hewitt in 1973. An ActorActorAn independent worker that owns some private state and has a mailbox. It handles one message at a time, and it can only affect the rest of the program by sending messages. has three parts:

What an actor may do with a message

While handling one message, an actor is allowed to do exactly three kinds of things:

1. Change its own state — "balance is now 150".
2. Send messages to actors it knows the addressAddress (PID / ActorRef)The handle you use to send a message to one specific actor, like an email address. Erlang calls it a PID (process id), Akka calls it an ActorRef. of — including a reply to whoever asked.
3. Create new actors — e.g. a "bank" actor that opens a new account actor for each customer.

That's it. It cannot read another actor's state or call its methods. The only way to affect another actor is to send it a message, which that actor will handle in its own time.

Try it

Each card is an actor: its locked private state (🔒), the message it's handling right now, and its mailbox. Every tick (about one second), each actor handles one message. They all work at the same time — but each one handles its own messages strictly one after another.

Things to notice:

• Burst five deposits while paused. They don't collide — they wait in line, and the balance goes up by 10 five times.
• A transfer is one message to alice. While handling it, alice changes her balance and sends a deposit to bob. Bob handles it later, on his own schedule. For a moment the money is "in the mail" — in neither balance. That's normal for actors: each actor's own state is always consistent, but the system as a whole catches up message by message.
• Withdraw more than the balance: pick @bob (50) and press withdraw 30 twice. The first succeeds; the second is refused. The check ("is there enough?") and the change happen inside one message, so nothing can sneak in between them. With a shared variable, two withdrawals could both pass the check and overdraw the account — a cousin of the race in §02. Here it can't happen.
• @bank: open account makes the bank actor create a brand-new actor.
• Every change also sends a record to @audit. Nobody waits for the audit log; it catches up on its own.

CSP in one paragraph — and the real difference

CSP in one paragraph. CSPCSPCommunicating Sequential Processes: a 1978 idea that independent workers should cooperate by passing messages, not by sharing variables. Go's goroutines and channels are built on it. (Tony Hoare, 1978) builds programs from independent workers that never share variables; they talk only through channels. In Go that means goroutines plus ch <- v and v := <-ch. An unbuffered channel stores nothing: the sender waits until a receiver takes the value, so the two meet — a handshake (called a rendezvous). A Buffered channelBuffered channelA channel with N storage slots: make(chan T, N). A send only waits when all N slots are full. adds N slots so the sender can run ahead. Either way, the value you send is handed over: once sent, it's the receiver's to use — that's what "the data moves" meant in §02. The Channels topic teaches all of this in depth — this page only needs the basics.

The two differences that matter

1. What has the name. With actors, the worker has an address and you send to it: "Alice, do this". With CSP, the channel has the name and the workers are anonymous: you put a job on jobs, and any goroutine reading jobs might take it.

2. Whether the sender waits. An actor's mailbox is a queue, so sending returns immediately — the message waits, not you. (In Erlang and Akka the mailbox has no size limit by default; §08 shows why that's a mixed blessing.) An unbuffered channel makes the sender wait for a receiver. (A buffered channel is in between: it's a small mailbox with a size limit.)

Watch both with the same job — a fast producer, a slow receiver:

Try 2 receivers: on the channel side, either receiver may take each value — the producer never named one. On the actor side nothing changes, because you addressed @printer. Then try buffer 3 and notice the channel starts to behave like a mailbox.

Side by side

Building an actor in Go

Go has no actor keyword, but it has everything needed: a GoroutineGoroutineA very lightweight task in Go, started with the go keyword. The Go runtime runs thousands of them on just a few OS threads. to run the actor, a Buffered channelBuffered channelA channel with N storage slots: make(chan T, N). A send only waits when all N slots are full. as its MailboxMailboxAn actor's personal queue of incoming messages. Senders drop a message in and move on; the actor takes them out one by one, oldest first., and a for loop that takes one message at a time. Callers make two kinds of requests: a telltell vs asktell = send a message and carry on without waiting (fire-and-forget). ask = send a request and wait for a reply, usually with a timeout. ("deposit this", send and move on) and an ask ("what's the balance?", wait for a reply). Here's the account from §03 as a complete program:

package main

import (
    "context"
    "fmt"
    "sync"
)

// The messages this actor understands.
type deposit struct{ amount int }
type getBalance struct{ reply chan int } // carries its own "return address"

type Account struct {
    inbox chan any // the mailbox; its channel is the actor's address
}

func NewAccount(ctx context.Context) *Account {
    a := &Account{inbox: make(chan any, 64)} // up to 64 messages can wait
    go a.loop(ctx)                            // start the actor's goroutine
    return a
}

// loop IS the actor. Only this goroutine ever touches bal.
func (a *Account) loop(ctx context.Context) {
    bal := 0 // private state
    for {
        select {
        case msg := <-a.inbox: // take ONE message…
            switch m := msg.(type) { // …see what kind it is…
            case deposit:
                bal += m.amount // …and handle it completely
            case getBalance:
                m.reply <- bal
            }
        case <-ctx.Done(): // someone asked the actor to stop
            return
        }
    }
}

// Friendly methods, so callers never build messages by hand.
func (a *Account) Deposit(n int) { a.inbox <- deposit{n} } // "tell": don't wait for a result

func (a *Account) Balance() int { // "ask": wait for the reply
    reply := make(chan int, 1)
    a.inbox <- getBalance{reply}
    return <-reply
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel() // stops the actor when main returns

    acct := NewAccount(ctx)
    var wg sync.WaitGroup
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func() { defer wg.Done(); acct.Deposit(1) }() // 100 goroutines, no lock
    }
    wg.Wait()                   // all 100 deposits are now in the mailbox…
    fmt.Println(acct.Balance()) // …and getBalance lines up behind them: 100
}

A few details carry the whole design:

• The inbox channel is the actor's address. Whoever holds acct (and so acct.inbox) can send it messages. Nobody can reach bal.
• The buffer is the mailbox size. If 64 messages are already waiting, Deposit blocks until the actor catches up. That's BackpressureBackpressurePushing back on whoever sends you work when you're full — making them wait or rejecting them — instead of piling it up in memory. — a feature Erlang and Akka mailboxes don't give you by default (§08).
• ctx.Done() stops the actor. Without it, the goroutine would wait on the inbox forever after everyone stops using it — a goroutine leak (see Channels §08). Note the flip side: once the actor has stopped, any messages still queued are never handled, and a later Deposit blocks forever as soon as the buffer is full. §10 (pitfall #7) covers how to guard against that.

Asking a question: the reply channel

Deposit is a tell: drop the message and move on. Balance is an ask: the caller needs an answer, but it can't read bal itself. So it makes a fresh channel, puts it inside the request, and waits on it. Step through it:

1func (a *Account) Balance() int {
2    reply := make(chan int, 1)    // my private "return address"
3    a.inbox <- getBalance{reply}  // the request carries it
4    return <-reply                // wait for the answer
5}
6 
7// inside the account's loop:
8case getBalance:
9    m.reply <- bal                // answer on the caller's channel

Two choices in that code matter:

1. make(chan int, 1) — one slot. The actor's m.reply <- bal can always complete, even if the caller already gave up and left. With an unbuffered reply channel, a caller that stopped waiting (you'll see such a caller in the timeout version below) would leave the actor stuck on that send — and a stuck actor stops reading its whole mailbox.
2. The answer reflects the mailbox order. getBalance was handled after the deposit that arrived before it, so the caller sees 150. Each answer is consistent with every message ahead of it in the queue.

The production version: never wait forever

The simple Balance() waits forever if the actor has stopped or is overloaded. Real code passes a context.Contextcontext.ContextA value passed as the first argument through Go calls that carries a deadline and a “stop now” signal. ctx.Done() is a channel you can receive from once it's time to stop. and gives up when it's cancelled or times out — the same thing Akka calls an ask timeout:

func (a *Account) Balance(ctx context.Context) (int, error) {
    reply := make(chan int, 1)
    select {
    case a.inbox <- getBalance{reply}: // the request got into the mailbox
    case <-ctx.Done():
        return 0, ctx.Err() // mailbox full for too long, or caller cancelled
    }
    select {
    case v := <-reply:
        return v, nil
    case <-ctx.Done():
        return 0, ctx.Err() // gave up waiting; the 1-slot reply channel keeps the actor safe
    }
}

// Caller: give it at most 200 ms.
//   ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
//   defer cancel()
//   bal, err := acct.Balance(ctx)

Actors in JavaScript: a mailbox class and Web Workers

JavaScript runs your code on one ThreadThreadOne worker that runs your code line by line. A program can have several threads, and the operating system decides which one runs on which CPU core., so you might think it doesn't need actors. Without any await, that's true: two pieces of JS never run at the same instant. But an async handler pauses at every await — and while it's paused, another call can start and read the same state. That's the race in Async / Await §07. A mailbox fixes it by refusing to start the next message until the current one is completely done:

The mailbox class

class Actor {
  #mailbox = [];     // waiting messages, oldest first
  #running = false;  // is the loop below already working?

  constructor(handler) { this.handler = handler; } // handler(msg) may be async

  send(msg) {                 // "tell": queue it and return at once
    this.#mailbox.push(msg);
    if (!this.#running) {                 // no loop yet? schedule one
      this.#running = true;
      queueMicrotask(() => this.#drain()); // runs right after the sender's current code
    }
  }

  ask(msg) {                  // "ask": the promise is the reply channel
    return new Promise((resolve, reject) => this.send({ ...msg, resolve, reject }));
  }

  async #drain() {
    while (this.#mailbox.length) {
      const msg = this.#mailbox.shift();          // take the oldest message
      try {
        await this.handler(msg);                  // ← finish it completely before the next
      } catch (err) {
        if (msg.reject) msg.reject(err);          // an ask gets the error back
        else console.error("actor failed on", msg, err);
      }
    }
    this.#running = false;
  }
}

Here is the loop at work, with a handler that pauses at an await:

1send(msg) {
2  this.#mailbox.push(msg);
3  if (!this.#running) {
4    this.#running = true;
5    queueMicrotask(() => this.#drain());
6  }
7}
8async #drain() {
9  while (this.#mailbox.length) {
10    const msg = this.#mailbox.shift();
11    await this.handler(msg);
12  }
13  this.#running = false;
14}
15 
16// handler: log "start", await sleep(10), log "end"
17actor.send("a");
18actor.send("b");

Why is #running safe without a lock? Because the only gaps where other code can run are the awaits. The final check while (this.#mailbox.length) and this.#running = false run together with no await between them, so a send can never slip in and find the loop "half-stopped" — it either sees #running === true and its message gets picked up by the loop, or sees false and schedules a new one.

Here is the same account as §05 in both languages. Switch tabs to compare:

function makeAccount() {
  let balance = 0;                       // private: only the handler can see it
  return new Actor(async (msg) => {
    switch (msg.type) {
      case "deposit":
        await auditLog.write(msg);       // some async API: a pause — but no other
                                         // message can start until this one finishes
        balance += msg.amount;
        break;
      case "balance":
        msg.resolve(balance);            // answer the ask
        break;
    }
  });
}

const acct = makeAccount();
acct.send({ type: "deposit", amount: 50 });      // tell
console.log(await acct.ask({ type: "balance" })); // ask → 50
// (await at the top level like this works in ES modules: .mjs files or <script type="module">)

The balance query returns 50, not 0, for the same reason as in §05: it sits behind the deposit in the mailbox, and the deposit's await finishes before the next message starts.

Web Workers: actors built into the platform

A Web Worker (or a Worker threadWorker threadAn extra JavaScript thread you create on purpose (Web Workers in browsers, worker_threads in Node) to run CPU-heavy code without freezing the main thread. in Node) runs JavaScript on another thread with its own memory. The page can't touch the worker's variables, and the worker can't touch the page's. They communicate only with postMessage, and each side handles incoming messages one at a time through its own Event loopEvent loopThe loop inside every JS runtime that repeatedly picks the next piece of waiting work (a callback) and runs it to completion on the single main thread.. Private state, a mailbox, one message at a time — that's an actor.

const counter = new Worker(new URL("./counter.js", import.meta.url), { type: "module" });

counter.onmessage = (e) => console.log("total is", e.data); // replies arrive here
counter.postMessage({ type: "add", n: 5 });  // tell: returns at once
counter.postMessage({ type: "add", n: 2 });
counter.postMessage({ type: "get" });        // → "total is 7"

postMessage copies the data with the Structured cloneStructured cloneThe algorithm postMessage uses to copy a value to another thread or window: it deep-copies objects, arrays, Maps, Dates and more — but not functions or class instances' methods. algorithm, so the worker gets its own copy — exactly like Erlang, where messages are copied between processes. (The exceptions are transferableTransferable objectA value such as an ArrayBuffer that postMessage can move to another thread instead of copying, if you list it in the transfer list: postMessage(buf, [buf]). The sender can no longer use it afterwards. objects such as an ArrayBuffer that you list in the transfer list — postMessage(buf, [buf]) — which are moved instead of copied, and SharedArrayBufferSharedArrayBuffer + AtomicsA block of raw bytes that several JS threads can see at the same time (real shared memory). Atomics gives safe operations on it, like an increment that can't be interrupted halfway., which really is shared — and brings back every problem from §02.)

Erlang, Elixir and Akka: supervisors and “let it crash”

Erlang was built at Ericsson in the 1980s for telephone switches that must never go down. Elixir (2012) is a friendlier language on the same virtual machine, the BEAMBEAMThe virtual machine that runs Erlang and Elixir code. It can run millions of tiny processes (actors) at once, each with its own memory and garbage collection.. Both call their actors processes — not operating-system processes, but tiny ones managed by the BEAM, starting at a few kilobytes each. A single machine can run millions. Akka brings the same ideas to the JVMJVMThe Java Virtual Machine: the runtime that executes Java, Scala and Kotlin programs. Akka runs on it. (Scala/Java); since its 2022 license change, Apache Pekko is its open-source fork.

An actor in Elixir

Erlang-family languages have actors built in: spawn creates one, send drops a message in its mailbox, receive takes the next message that matches a pattern.

defmodule Counter do
  def loop(count) do                 # the actor's state is the argument
    receive do                       # take the next matching message
      {:add, n} ->
        loop(count + n)              # "change state" = loop again with a new value
      {:get, from} ->
        send(from, {:count, count})  # reply to whoever asked
        loop(count)
    end
  end
end

pid = spawn(fn -> Counter.loop(0) end)  # create an actor; pid is its address
send(pid, {:add, 5})                    # tell: returns immediately
send(pid, {:get, self()})               # ask: "reply to me" (self() = my own pid)

receive do
  {:count, c} -> IO.puts(c)             # 5
end

In real Elixir code you rarely write receive by hand. GenServer wraps this loop for you: GenServer.cast is a tell, and GenServer.call is an ask that waits for the reply — with a 5-second timeout by default, so a stuck actor can't hang the caller forever.

Supervisors and "let it crash"

Here's the twist that makes Erlang famous. A SupervisorSupervisorAn actor whose only job is to start other actors (its children), watch them, and restart them when they crash. is an actor whose only job is to start some child actors, watch them, and restart any that crash. Supervisors can supervise other supervisors, forming a supervision tree. The whole app is one tree.

That makes a different error-handling style possible: Let it crashLet it crashErlang's approach to unexpected errors: don't write defensive code for every possible failure inside a worker. Let it die, and let its supervisor restart it in a clean, known-good state.. Don't wrap every line in defensive checks for situations you didn't expect. If a chat-room process gets into a weird state, let it crash; its supervisor starts a fresh copy in a known-good state a millisecond later. Crashing is safe because the room's state was private — nothing else was half-updated when it died.

What the demo shows:

• The restart strategies. one_for_one: restart just the crashed child — the usual choice. one_for_all: restart all children — for children that can't work without each other. rest_for_one: restart the crashed child and all children started after it — for when later children depend on earlier ones.
• Restart limits. Crash rooms quickly: after too many restarts in a short window (Elixir's default is 3 in 5 seconds; the demo uses 10 s), the supervisor decides restarting isn't helping, stops its children and crashes itself. Its own supervisor then restarts that whole branch. Failures climb the tree until a level that can fix them — and the logger, in another branch, never notices.
• Restarting loses in-memory state. The room comes back empty. "Let it crash" only works if anything important was saved somewhere durable (a database, an event log) before the crash.

Across machines: location transparency

A message to an Erlang process looks the same whether that process is in your program or on another machine: send(pid, msg). The BEAM connects nodes over the network and routes the message. This is called Location transparencyLocation transparencySending a message to an actor looks exactly the same whether that actor runs in your program or on another machine.. Akka Cluster and Microsoft Orleans do the same on their platforms — Orleans even creates an actor automatically the first time someone sends it a message ("virtual actors").

It works because actors were never sharing memory in the first place: a message was already a copy sent to an address. Go channels don't stretch this way — a channel is a value in one program's memory, and an unbuffered send's handshake can't cheaply span a network.

Mailboxes in production: overflow, backpressure, ordering

Overflow: a worked example

An actor handles 5 messages per second. Messages arrive at 8 per second. Every second, 3 more join the queue than leave it:

• after 1 minute: ~180 messages waiting; a new message waits ~36 s before it's handled;
• after 1 hour: ~10,800 waiting; a new message waits ~36 minutes.

Nothing errors. The wait for each message (its LatencyLatencyHow long one request or job takes from the moment it arrives until it's finished — including any time spent waiting in a queue.) just climbs until callers time out, and memory climbs until the process is OOM-killedOOM-killed“Out of memory”: the system kills a program that uses more memory than allowed.. Erlang and Akka mailboxes are unbounded by default, so this is the classic actor outage. Try the three policies:

The three options, and when each fits:

Ordering: what you can and can't rely on

Messages from one sender to one receiver arrive in the order they were sent — Erlang and Akka both promise that, and a Go channel is first-in-first-out too. But there is no global order. When messages travel along different paths, a later message can overtake an earlier one:

The practical rules:

• Two messages from you to one actor: safe to rely on their order. (Quiz question 1 depends on this.)
• Messages from several senders: they interleave in whatever order they arrive. If order matters, have one actor sequence them, or put a sequence number in each message.
• Messages that travel different paths (the right side of the diagram): A sent x to C before it sent y to B, and z only exists because B got y. It feels like x "must" reach C before z — but nothing promises it. Don't build logic on that kind of cause-and-effect order across actors unless your protocol enforces it (for example, A waits until C confirms x before sending y).

Actors or channels? How to choose

Shapes that want actors

Something that has an identity, lives for a long time, keeps state, and receives requests from many places:

• A chat room. One actor per room holds the member list and recent messages. Joins, leaves and posts arrive from many users; the room handles them one at a time, so "post" can never see a half-updated member list.
• A game entity or a game match. One actor per match owns positions and scores and processes moves in order.
• A bank account, a shopping cart, a user session, a device connection. One actor per id. Millions of mostly idle actors are cheap on the BEAM — and the per-id split is how you scale: different accounts are handled in parallel, while each single account stays strictly serial.

Shapes that want channels

Data that flows through steps, where no step has to remember much between items:

• Pipelines: read → parse → transform → write (Channels §06).
• Worker pools and fan-out: "resize these 10,000 images with 8 workers" (Channels §07). The workers are interchangeable, so naming them would only get in the way.
• Coordination signals: "stop now" (ctx.Done()), "first result wins" (select), timeouts.

The decision table

What your language nudges you toward

• Go makes channels and goroutines free and built in, so most Go code is CSP plus mutexes. The actor shape (§05) appears whenever one goroutine owns a resource: a connection, a cache that needs batched writes, a rate limiterRate limitA cap on how many requests are allowed per unit of time — e.g. 100 per second. It says nothing about how many may be running at once..
• JavaScript has no shared-memory threads by default, so locks are rare. Use the mailbox class (§06) to serialize async work on one thing, and Workers when you need real parallelism.
• Erlang/Elixir and Akka make actors the default, with supervisors and distribution included — the strongest choice when uptime and many machines matter.

Pitfalls gallery

1// Actor A ("orders"), handling one message:
2case placeOrder:
3    p := prices.Price(m.item) // ask B, then WAIT for its reply
4    m.reply <- p * m.qty
5 
6// Actor B ("prices"), handling one message:
7case restock:
8    n := orders.Stock(m.item) // ask A, then WAIT for its reply
9    setPrice(m.item, n)

select {
case prices.inbox <- getPrice{id: m.id, item: m.item, replyTo: a.inbox}:
case <-time.After(100 * time.Millisecond):
    m.reply <- errBusy // prices is overloaded: fail this request instead of jamming
}

case report:
    rows, err := db.Query(m.sql) // 2 s — the whole mailbox waits
    m.reply <- summarize(rows, err)

case report:
    snapshot := a.copyState()        // quick: just the data the job needs
    go func() {                      // the slow part runs elsewhere…
        m.reply <- buildReport(snapshot)
    }()                              // …and the actor goes straight back to its mailbox

case getAll:
    m.reply <- a.items  // the caller now shares the actor's map!

case getAll:
    m.reply <- maps.Clone(a.items) // send a copy (import "maps", Go 1.21+)

Check yourself

Predict the answer before you click. Where to look if you miss one: Q1 in §03 and §08, Q2 in §05 and §10, Q3 in §04 and §07, Q4 in §06, Q5 in §07, Q6 in §09.

// An account actor with balance 40.
// ONE sender does, in this order:
acct.send({ type: "deposit",  amount: 50 });
acct.send({ type: "withdraw", amount: 80 });
// (withdraw is refused if balance < amount)

// inside the account's loop (the only goroutine reading a.inbox)
case deposit:
    bal += m.amount
    log.Println("new balance:", a.Balance()) // Balance() from §05

# Elixir. counter is busy with a slow message right now.
send(counter, {:add, 1})
IO.puts("next line")

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const logger = new Actor(async (msg) => {   // the Actor class from §06
  console.log("start", msg);
  await sleep(10);
  console.log("end", msg);
});
logger.send("a");
logger.send("b");

chat supervisor, strategy: rest_for_one
children, in start order:  lobby, games, music
→ games crashes

Job: read 1 million image files, resize each,
then upload. No state needs to be kept between images.

Cheat sheet