Erlang and the Actor Model
Zusammenfassung
Erlang was created in the mid-1980s at Ericsson by Joe Armstrong, Robert Virding, and Mike Williams to solve one of the hardest problems in computing: building telephone switches that must run for years without stopping, recover from their own faults, and be upgraded while running. The solution was a language built around millions of lightweight isolated processes that communicate only by passing messages — a practical realization of the actor model. Erlang’s “let it crash” philosophy and its “nine nines” (99.9999999%) reliability record made it the quiet backbone of telecom, and its ideas resurfaced in WhatsApp, Discord, and a generation of distributed systems.
The Telecom Reliability Problem
In the 1980s, Ericsson, the Swedish telecommunications giant, faced a software crisis. Telephone exchanges had requirements unlike almost any other software: they had to handle hundreds of thousands of simultaneous calls, run continuously for years (downtime measured in minutes per decade), recover automatically from hardware and software faults, and be upgraded without being shut down. No existing language made these properties easy to achieve.
At the Ericsson Computer Science Laboratory, Joe Armstrong, Robert Virding, and Mike Williams spent the late 1980s experimenting. Armstrong began by prototyping telephony features in Prolog, then evolved the work into a new language. The result, named Erlang (after the Danish mathematician Agner Krarup Erlang, founder of queueing theory — and conveniently a contraction of “Ericsson Language”), first ran in 1986 and was used internally through the early 1990s.
The flagship product was the AXD301 ATM switch, a massive Erlang system that achieved a documented reliability of nine nines — 99.9999999% uptime, roughly 31 milliseconds of downtime per year.
The Actor Model in Practice
Erlang is the most successful practical implementation of the actor model of concurrency (see Concurrency and Parallelism; formulated theoretically by Carl Hewitt in 1973). Its core principles:
- Lightweight processes: Erlang processes are not OS threads; they are managed by the Erlang virtual machine (the BEAM) and are so cheap that a single system can run millions of them simultaneously. Each has its own isolated memory.
- No shared state: processes share nothing. There are no locks, no mutexes, no shared memory to corrupt.
- Message passing: processes communicate exclusively by sending asynchronous messages to each other’s mailboxes. This is the only way they interact.
- Location transparency: a message to a process works the same whether that process is on the same machine or another machine across the network, making distributed systems a natural extension of local ones.
This architecture made concurrency safe by construction. The bugs that plague shared-memory threading — race conditions, deadlocks, corrupted state — largely cannot occur, because there is no shared memory to race over.
“Let It Crash”
Erlang’s most counterintuitive idea was its approach to error handling: let it crash. Instead of defensively checking for every possible error and trying to recover in place, an Erlang process that encounters an unexpected situation simply dies. The cleanup is handled elsewhere.
This works because of supervision trees: processes are organized hierarchically, with supervisor processes whose only job is to monitor worker processes and restart them when they fail, returning the failed component to a known-good state. The philosophy assumes that the system as a whole must survive even though individual parts fail constantly — exactly the right assumption for telecom-scale reliability.
Combined with hot code swapping — the ability to upgrade running code without stopping the system — these features gave Erlang its defining capability: software that runs essentially forever.
OTP and the Open Source Era
In 1998, Ericsson open-sourced Erlang, releasing it together with OTP (Open Telecom Platform) — a set of libraries and design principles (generic servers, supervisors, finite state machines) that encode the battle-tested patterns of building fault-tolerant systems. “Erlang/OTP” is how the platform is almost always used.
The same year, Ericsson briefly banned Erlang for new projects internally, pushing toward off-the-shelf languages — a decision widely regarded as a strategic error, since open-sourcing it ensured its survival and growth outside the company.
Influence and Descendants
Erlang’s ideas spread well beyond telecom:
- WhatsApp famously ran a service of hundreds of millions of users with a tiny engineering team, built on Erlang, before and after its 2014 acquisition by Facebook (see The Social Media Revolution).
- Discord, RabbitMQ (a widely used message broker), and CouchDB are built on the BEAM.
- Elixir, created by José Valim in 2011, is a modern language with Ruby-inspired syntax that runs on the BEAM and brought the Erlang concurrency model to a new generation of web developers via the Phoenix framework.
- The actor model Erlang proved practical reappeared in Akka (Scala/JVM), Microsoft Orleans, and the concurrency designs of many later systems.
Legacy
Erlang answered a question most languages never seriously asked: how do you build software that simply does not stop? Its answer — isolated lightweight processes, message passing, supervision, and “let it crash” — was so well suited to distributed, fault-tolerant systems that decades later it remains the reference design for high-availability backends. Joe Armstrong (who died in 2019) articulated a worldview in which failure is normal and resilience comes from structure, not from preventing every error — an idea that has aged into orthodoxy as the whole industry moved to distributed systems.
📚 Sources
- Erlang — official site
- Wikipedia: Erlang (programming language)
- Joe Armstrong: A History of Erlang (HOPL III, 2007)
- Joe Armstrong: Making reliable distributed systems in the presence of software errors (PhD thesis, 2003)
- Carl Hewitt et al.: A Universal Modular ACTOR Formalism for Artificial Intelligence (1973)