Chapter 1: Why Erlang? Why Now? Why Ever?
In 1986, a bunch of Swedish engineers at Ericsson got tired of telephone switches crashing. So they invented a programming language where crashing is a feature. This is that language’s story.
The Elevator Pitch (That Never Gets Stuck)
Here’s the thing about Erlang: it was never supposed to be cool.
It wasn’t designed by language nerds trying to publish papers. It wasn’t born in a Silicon Valley garage. It was created by telecom engineers who had one job — keep phone calls connected — and a very real problem: their software kept dying.
So they built a language around a simple, radical idea: what if we just assumed everything would fail, and designed the whole system around recovering from failure?
That’s it. That’s the whole pitch. And it turns out that idea is the most important idea in software engineering that most programmers have never heard of.
But It’s Old!
Yes. Erlang is old. It’s older than Python. It’s older than Java. It’s older than most of the people writing JavaScript frameworks on Hacker News.
You know what else is old? TCP/IP. Unix. The relational model. SQL. Some ideas are so good they don’t need to be reinvented every three years.
Erlang isn’t old because it’s outdated. Erlang is old because it was ahead of its time. The rest of the industry is just now catching up to ideas Erlang had in the late ’80s:
- Isolated processes? That’s microservices. Erlang had it in 1986.
- Message passing between services? That’s Kafka, RabbitMQ, event-driven architecture. Erlang had it in 1986.
- Crash recovery with supervisors? That’s Kubernetes restart policies. Erlang had it in 1986.
- Hot code reloading? Your CI/CD pipeline with blue-green deployments is a Rube Goldberg machine around something Erlang does natively.
What Makes Erlang Different
Most languages are designed around computing things. Erlang is designed around running systems.
Here’s what that means in practice:
Lightweight Processes
Erlang processes are not OS threads. They’re insanely lightweight — a fresh process takes about 300 words of memory. You can spawn millions of them on a single machine. Each one has its own heap, its own garbage collector, and its own mailbox.
%% Spawn a process. That's it. That's the whole thing.
Pid = spawn(fun() -> io:format("Hello from process ~p!~n", [self()]) end).
No Shared State
Processes don’t share memory. They communicate by sending messages. This means no mutexes, no locks, no data races, no “hey why is this variable suddenly null.”
%% Send a message
Pid ! {hello, "world"}.
%% Receive a message
receive
{hello, Msg} -> io:format("Got: ~s~n", [Msg])
end.
Fault Tolerance Is Built In
When an Erlang process crashes, it doesn’t take the system down. Other processes notice, clean up, and restart it. This isn’t a library or a framework — it’s the foundation of the language.
Hot Code Reloading
You can upgrade Erlang code on a running system without stopping it. Ericsson needed phone switches that ran for years without downtime. So they built a language that supports it.
Who Uses This Stuff?
- WhatsApp handled 2 million concurrent connections per server with a tiny team, all on Erlang. When Facebook bought them for $19 billion, the engineering team was about 50 people.
- RabbitMQ, one of the most popular message brokers in the world, is written in Erlang.
- Ericsson still runs half the world’s telecom infrastructure on it.
- Discord uses Elixir (which runs on the same VM) for their real-time messaging.
- Cisco, Klarna, Bet365, and dozens of other companies bet big on the BEAM.
The Joe Armstrong Philosophy
Joe Armstrong, Erlang’s co-creator, had a way of explaining things that cut right through the nonsense. His core insight was this:
You can’t prevent failure. Hardware fails. Networks fail. Code has bugs. The question isn’t “how do I prevent this process from crashing?” The question is “when this process crashes, what happens next?”
In most languages, the answer is “everything falls over.” In Erlang, the answer is “something else notices, cleans up, and starts fresh.”
That’s the “let it crash” philosophy. And it changes everything.
What You’ll Learn in This Book
We’re going to start from zero and take you through:
- The basics — syntax, data types, pattern matching, functions
- Concurrency — processes, message passing, the BEAM VM
- Fault tolerance — links, monitors, supervisors, “let it crash”
- OTP — the framework that turns Erlang from a language into a superpower
- Advanced topics — ETS, Mnesia, distributed systems, hot code reloading
- Real-world stuff — how actual companies use this in production
By the end, you’ll understand why people who use Erlang never shut up about it. And you’ll probably be one of them.
Let’s Go
Fire up your terminal. We’ve got a language to learn and some processes to crash.