F0 · History · optional
The evolution of Erlang, the BEAM & OTP
F0.1 traced the language. This one traces the machine — a runtime built for telephone switches that turned out to be exactly what real-time systems need.
Where the functional lineage gave Elixir its way of thinking, the BEAM gave it a place to run: cheap processes, a scheduler that keeps every one of them responsive, and a supervision model that treats failure as routine. Three dives follow the overview, each pairing a runtime idea with the Elixir that sits on top of it.
One machine, six steps
Erlang began at Ericsson in 1986 as an answer to a hard question: how do you run a telephone exchange that must stay up for years, handle enormous concurrency, and survive its own bugs? The answers became a runtime. Select a step to read what it added and where it lands in Elixir.
The runtime · select a step
A language for telephone switches: enormous concurrency, fault tolerance, soft real-time response, and upgrades without downtime.
The hard requirements of a phone network — never stop, never block, recover on your own — are the same ones a real-time web system has. Elixir gets the answers for free because the BEAM already had them.
Telecom roots & “let it crash”
A telephone exchange handles thousands of independent calls at once, and a fault on one call must never touch the others. Erlang answered with isolated processes: no shared memory, no shared state, only messages between them. A failure has nowhere to spread.
That isolation makes a different error strategy possible. Instead of guarding every operation against every fault, you let a process crash on the unexpected and have a supervisor restart it from a known-good state. The transient, broken state dies with the process; the system continues. Defensive code shrinks to the cases you actually understand.
Erlang, 1986
A worker crashes on a fault. Its state is gone, but a supervisor restarts it clean. The fault stays local.
Elixir, today
Return {:error, reason} for the expected, and let it crash for the rest — a Supervisor brings the worker back.
Let it crash · a worker that heals
A crash is contained to one process, and recovery is the default rather than an emergency. F3.07 builds processes, F3.08 builds the GenServer that holds state, and F5.04 is “let it crash” applied to real systems.
Inside the BEAM — scheduling, heaps & soft-real-time GC
Processes on the BEAM are not operating-system threads. Each one is a lightweight unit the virtual machine manages itself, small enough that a single node runs millions of them. Two design choices make that practical.
The first is preemptive scheduling by reduction counting. Each process is given a budget of work — roughly two thousand reductions, one per function call — and when it spends the budget the scheduler pauses it and runs another. No process can hold a core, so a slow computation never starves the rest. The second is per-process heaps: every process owns its memory, so garbage collection is local and brief, with no global stop-the-world pause. Messages are copied between heaps, which is what keeps the processes share-nothing.
The BEAM scheduler
A reduction budget, then preemption — one scheduler per core, every process kept responsive.
Elixir, today
spawn is cheap, and a slow function can’t freeze the others — the reason a server stays responsive under load.
Reductions · one long job, two short jobs
The BEAM keeps every process moving by counting its work and stepping aside. Throughput is about the same either way; what changes is latency — and that is why one slow request does not stall a whole server. F6 builds on exactly this.
OTP & the supervision tree — and the polyglot BEAM
OTP — the Open Telecom Platform — is the set of patterns that turn isolated processes into a dependable system. Its core is the supervision tree: supervisors whose only job is to start children and restart them when they fail, according to a declared strategy. Failure handling stops being scattered through the code and becomes a shape you can read at the top of the tree.
One runtime now carries more than one language. Erlang, Elixir, Gleam, and others compile to BEAM bytecode, share the scheduler and the supervision model, and call one another directly. Elixir is one language on a machine built to outlast any single one of them.
OTP supervision
A supervisor restarts its children by a strategy — one, all, or the rest started after the one that failed.
Elixir, today
Supervisor.start_link(children, strategy: :one_for_one) — the tree, declared.
Supervision · pick a strategy, crash a child
- one_for_one
- only the child that crashed is restarted; its siblings keep running.
- one_for_all
- every child is restarted, because they depend on one another.
- rest_for_one
- the crashed child and every child started after it are restarted, in order.
The supervision tree turns failure into a declared, local recovery rather than a special case. F3.08 builds it in Elixir, and F6.09 ends the course with a real-time dashboard held up by one.
What this lands
Three runtime ideas carry forward. Isolated processes and “let it crash” become Elixir’s processes and supervisors (F3.07–F3.08) and its everyday error handling (F5.04). The reduction-counting scheduler is why concurrency in Elixir stays fair under load, and why F6 · Phoenix can keep thousands of live connections responsive. The supervision tree is the backbone every production application is built around.
With F0.1 and F0.2 in place, the history is complete: a functional lineage that shaped how Elixir thinks, and a runtime that shaped what it can do. The course proper starts from the mathematics, where the next chapter begins.
This completes F0 · History. The course proper begins at F1 · Algebra — the functional mindset, straight from the math you already know.