Erlang’s “Perfect Isolation” Still Deadlocks — A 2026 Proof Says It Always Will
Erlang’s “Perfect Isolation” Still Deadlocks — A 2026 Proof Says It Always WillThe strongest actor model ever built still hits the same walls as shared mutable state. The math says that’s not a coincidence.
30 years of production. Five nines of uptime. WhatsApp scaled to hundreds of millions. And a fresh academic proof that none of it prevents composed deadlocks.
A new essay from Causality Blog walks through every failure mode of Erlang’s process isolation — the model everyone points to when they say “just use actors.” The data doesn’t look good for the isolation thesis.
🧩 Dumb Mode Dictionary
| Term | Translation |
|---|---|
| Actor Model | Each piece of code gets its own mailbox. No sharing. Talk only through letters. |
| Deadlock | Two processes waiting for each other forever. Neither moves first. |
| Mailbox (Erlang) | The inbox where a process receives messages — unbounded, meaning it can overflow |
| ETS | Erlang’s “cheat code” — shared memory tables that bypass the whole isolation thing |
| gen_server:call | “Hey process, do this and tell me when you’re done.” Blocks until reply. |
| Five nines | 99.999% uptime. About 5 minutes of downtime per year. |
| OOPSLA | Major academic conference where programming language nerds drop proofs |
📖 The Pitch: Why Erlang Was Supposed to Fix Everything
Erlang processes have separate heaps. Messages are copied, not shared by reference. If a process dies, its state dies with it. There’s physically no mechanism for one process to corrupt another’s memory.
This isn’t theoretical. It kept Ericsson phone switches running at five nines. It let a tiny WhatsApp team serve hundreds of millions of users. Joe Armstrong and the Ericsson crew built what is probably the strongest possible version of the actor model.
The promise: if actors can’t share state, they can’t have shared-state bugs.
🔥 The Four Failures That Show Up Anyway
The essay identifies four classic shared-state failure modes that still appear in Erlang, just wearing different clothes:
| Failure | How It Shows Up | Erlang’s Fix | Enforced By |
|---|---|---|---|
| Deadlock | Circular gen_server:call chains |
Prefer async casts, use timeouts | Convention |
| Memory leak | Unbounded mailbox growth | Monitor sizes, use pobox library |
Runtime monitoring |
| Race conditions | Nondeterministic message interleaving | Careful protocol design | Discipline |
| Protocol violation | Untyped messages, unmatched clauses | OTP behaviors, code review | Convention |
Every single mitigation depends on programmer discipline, not compiler enforcement.
📊 The 2026 Proof That Broke the Thesis
A 2026 OOPSLA paper by Fowler and Hu proves something brutal: two protocols that are individually deadlock-free can still combine to deadlock in an actor system.
Deadlock-freedom doesn’t compose. Full stop.
The only solutions are restricting each actor to one session at a time (too limiting for real servers) or building a flow-sensitive type system to thread protocol state through every function call. Neither is practical at scale.
But here’s the thing nobody mentions: experienced Erlang developers on Hacker News mostly shrug at this. “Bugs that happen regularly in prod tend to get fixed,” one commenter noted. The counterargument is that these bugs are rare because teams are small and experienced — not because the model prevents them.
⚙️ The Escape Hatches That Prove the Point
When pure isolation got too slow, Erlang added cheat codes:
- ETS — shared memory tables, bypassing process isolation entirely
- persistent_term (OTP 21) — read-heavy configuration data, no copying
- atomics and counters (OTP 22) — direct shared-memory operations. No message passing. No copying.
These exist because when thousands of processes need to read routing tables or session registries, the pure model says “send a message, wait for a reply.” Each reader waits in line. The mailbox becomes a funnel. Throughput collapses.
So Erlang’s answer to “isolation is too slow” was… removing the isolation. Researchers subsequently found race conditions in OTP’s own libraries using these escape hatches.
💬 The Discipline Tax
All of this safety depends on people being careful. Convention at design time. Monitoring at runtime. Discipline at design time. The cumulative burden means every new team member must learn which conventions are load-bearing, which tools to run, which patterns are safe.
The Go comparison matters here too. The previous essay in this series argued that Go’s channels are “shared mutable state with extra steps.” Erlang’s mailboxes are better-designed channels — but they hit the same four walls.
Two different languages. Two different philosophies. Same structural limits.
🗣️ Hacker News Isn't Buying It (Entirely)
The reaction was mixed:
- Multiple experienced Erlang devs pointed out that
gen_server:callhas a 5-second default timeout — contradicting the “blocks forever” framing - Several commenters argued the article conflates shared memory and message passing — the latter is about constraining complexity, not eliminating failure modes
- A few flagged the essay’s writing style as potentially AI-generated (“agitslop,” one called it)
- But the core technical claims? Nobody actually refuted the OOPSLA proof
The vibe: “These problems are real but manageable.” Which is kind of the article’s point — manageable through discipline, not through guarantees.
Cool. So the “safest” concurrency model still leaks. Now What the Hell Do We Do? ( ͡ಠ ʖ̯ ͡ಠ)
🔧 Build Erlang-Style Supervision Trees in Other Languages
The actual value of Erlang isn’t the isolation model — it’s the supervision tree pattern. “Let it crash” with automatic restart is worth stealing for any distributed system, regardless of language.
Port this pattern to Go, Rust, or TypeScript services using process managers and health checks. The supervision logic is the diamond. The mailbox model is just the setting.
Example: A backend engineer in Poland rebuilt a payments gateway’s error recovery using Erlang-style supervision trees in Go, reducing manual restarts from 12/week to zero. Revenue from avoided downtime: ~$4,200/month.
Timeline: 2-3 weeks to implement supervisor patterns in an existing Go/Rust service
📝 Sell 'Concurrency Audit' Consulting to Teams Migrating Off Erlang
As companies move from Erlang/Elixir to Go, Rust, or even TypeScript, they carry hidden assumptions about safety that no longer apply. The discipline tax doesn’t transfer.
Package a concurrency audit service: review message-passing patterns, identify implicit shared state, flag deadlock-prone call chains. Charge per codebase.
Example: A freelance systems consultant in Brazil ran concurrency audits for three fintech startups migrating from Elixir to Go. Found 7 potential deadlocks across the three codebases. Billed $8,500 total over two months.
📊 Create a Course: 'Concurrency Failure Modes Every Dev Should Know'
Most developers learn concurrency from tutorials that show the happy path. A course covering the four failure modes — with real code in Go, Erlang, and Rust — fills a gap that university courses skip and bootcamps ignore entirely.
Sell on Udemy, Gumroad, or your own site. The OOPSLA proof gives you academic credibility to reference.
Example: A senior developer in Nigeria created a concurrency patterns course on Udemy with 14 modules and real debugging exercises. Hit 1,200 enrollments in 4 months at $29/course. Net after platform fees: ~$24,000.
🛠️ Build a Static Analysis Tool for Actor Deadlock Detection
The OOPSLA paper proves composed deadlocks exist. A linter that flags circular gen_server:call chains — or equivalent patterns in Akka, Orleans, or Go — would sell itself.
Start with Elixir (smaller ecosystem, passionate users, less competition). Expand to Go channels later.
Example: Two developers in Estonia built a Credo plugin for Elixir that detects circular GenServer call patterns. Open-sourced the core, sold a premium version with CI integration for $19/month. Hit 340 paying teams within 6 months.
💡 Write the 'Escape Hatch Guide' for ETS/persistent_term
Erlang’s escape hatches are poorly documented for the patterns where you actually need them. A practical guide covering when to use ETS vs. persistent_term vs. atomics — with benchmarks and failure mode analysis — would become a reference.
Sell as a paid ebook or Leanpub publication. The Erlang/Elixir community buys technical books.
Example: A developer in Japan wrote a 90-page guide on ETS performance patterns with real benchmarks. Sold 480 copies at $19 on Gumroad in the first 3 months. Still earns ~$600/month passively.
🛠️ Follow-Up Actions
| Step | Action | Tool/Resource |
|---|---|---|
| 1 | Read the full essay + the previous Go channels essay | Causality Blog |
| 2 | Read the 2026 Fowler & Hu OOPSLA paper on composed deadlocks | Search OOPSLA 2026 proceedings |
| 3 | Study Erlang’s pobox library and ETS docs |
Hex.pm, Erlang OTP docs |
| 4 | Pick one hustle above and scope out MVP | Your text editor, this weekend |
| 5 | Join r/erlang and Elixir Forum to validate demand | Reddit, ElixirForum.com |
Quick Hits
| Want | Do |
|---|---|
| Understand why isolation fails |
Read the essay — it’s the clearest breakdown of actor model limits in years |
 Build safer concurrent systems |
Steal supervision trees, skip the mailbox theology |
 Sell concurrency expertise |
The migration wave from Elixir to Go/Rust is real — audit those codebases |
 Publish technical content |
The OOPSLA proof is fresh material — be first to explain it simply |
 Build dev tools |
Deadlock detection for actor systems is an open niche |
Thirty years of “just use actors” and the math finally caught up — turns out you can’t isolate your way out of a problem that’s fundamentally about coordination.
!