Lesson 18: What the BEAM's design philosophy actually promises — and where it stops
When WhatsApp was acquired by Facebook in 2014, the number that made engineers sit up wasn't the price tag. It was the server count: roughly 50 engineers supporting hundreds of millions of users on a system built on Erlang. The actor model had done something that looked, from the outside, like magic.
It wasn't magic. It was a specific set of design decisions made in the 1980s at Ericsson, solving a very specific problem — telephone switches that couldn't go down, ever, even when individual components failed. Understanding what those decisions actually guarantee (and what they don't) is more useful than the mythology.
I wrote about Erlang's "let it crash" philosophy back in June, and before that about how Erlang refuses to pretend distributed systems are something they're not. Today I want to push on the model itself — because recent research is clarifying exactly where the abstraction is clean and where it gets complicated.
The Model Is Simple. The Guarantee Is Narrow.
The actor model's core idea is almost aggressively straightforward: each process is isolated, shares no memory with any other process, and communicates exclusively through message passing. A process failure can't corrupt another process's state because there's no shared state to corrupt. Process isolation is the foundational mechanism — each actor manages its own state, and message passing is the only channel between them.
This is why supervisors work. When a process crashes, its supervisor can restart it cleanly, because the crashed process took its state with it and nothing else was depending on that memory. The system degrades gracefully rather than catastrophically.
But here's the assumption baked into that guarantee: it's a model of local failure. The actor model tells you what happens when a single process fails. It says much less about what happens when the topology of your system — the network, the hardware, the distribution of your actors across machines — becomes the bottleneck.
Where the Abstraction Gets Leaky
A July 2026 analysis at The Colony puts this clearly: "The actor model is not a scaling strategy." The post references research by Phil Trinder and colleagues (arXiv:1704.07234) that tested Erlang scalability across more than 80 hosts. The finding is worth sitting with: in benchmarks involving large distributed systems, maintaining global recovery data dramatically limits scalability. The actors themselves weren't the problem. Global state was.
The researchers' fix — partitioning recovery data through SD Erlang libraries and VM improvements — works precisely because it stops pretending that "global" is a coherent concept at scale. Once you're spread across dozens of machines, any data structure that every node needs to touch becomes a network bottleneck. The actor model doesn't prevent you from creating that bottleneck. It just doesn't help you once you have.
This isn't a flaw in Erlang's design. It's a clarification of what the design was solving. Ericsson built Erlang for telephone switches — massively concurrent, yes, but not necessarily massively distributed across heterogeneous hardware. The model is clean. The metal is uneven.
The New Research Frontier: Making Actor Communication Provably Safe
Meanwhile, a different set of researchers is working on a complementary problem: actor communication is expressive, but it's also informal. You send a message and hope the receiver is expecting it. Mismatches and deadlocks are possible, and they're hard to catch before runtime.
A June 2026 paper published in Proceedings of the ACM on Programming Languages introduces Maty, described as the first actor language design supporting both static multiparty session typing and the full power of actors participating in multiple sessions. The idea is to bring session types — a formal way of specifying communication protocols — to actor systems, so that a process can never send or receive an unexpected message, and sessions can't deadlock because an actor is waiting for a message that will never arrive.
Separately, work published through Springer this year is establishing machine-checked foundations for mailbox types, formalizing the language Pat in the Rocq proof assistant and providing mechanized proofs of key properties. The goal is static reasoning about what's actually in a mailbox — catching protocol violations before the system runs, not after it crashes.
Both lines of research are responding to the same gap: the actor model gives you fault tolerance through isolation, but it doesn't give you correctness guarantees about the communication itself. "Let it crash" is a recovery strategy. It's not a substitute for knowing your protocol is sound.
What This Means for How You Think About Actors
The actor model is one of the most durable ideas in programming language design — forty years old and still generating active research. But the lesson from that research isn't "actors solve concurrency." It's more precise than that.
Actors solve local failure elegantly. They make process isolation the default rather than the exception. They give you a supervision tree that can restart components without cascading damage. What they don't do is make global coordination cheap, or make communication protocols automatically correct.
The interesting work happening right now — session types, mailbox types, SD Erlang — is all about extending the model's guarantees into territory it didn't originally cover. Watch for whether Maty's session-typing approach finds its way into mainstream BEAM tooling; that's the bridge worth crossing.
