Part 2 · 1 chapters · ~8 min

The BEAM

The Erlang VM and its telecom origins, schedulers per core, reductions and preemptive scheduling, processes with private heaps and mailboxes, per-process garbage collection, message copying and large binaries, ETS tables, dirty schedulers and NIFs, hot code loading, distribution between nodes, and observing a live system with :observer and recon.

3

A runtime built for uptime

code
System.schedulers_online()            # 12 on this machine (Apple M3 Pro)
:erlang.system_info(:otp_release)     # '29'
:erlang.memory()                      # total, processes, binary, ets, atom …
:observer.start()                     # GUI: processes, memory, schedulers, live

# ETS: in-memory tables shared across processes, constant-time lookups
:ets.new(:rates, [:named_table, :set, :public, read_concurrency: true])
:ets.insert(:rates, {"USD-NGN", 1_532_00})
[{_, rate}] = :ets.lookup(:rates, "USD-NGN")

Origins: Erlang was created at Ericsson in 1986 for telephone switches that had to run for years with failures in parts of the system; the AXD301 switch was famously reported at nine nines of availability. WhatsApp scaled to hundreds of millions of users on Erlang with a small engineering team; Discord uses Elixir for its real-time services.

THE BEAM VIRTUAL MACHINE
why Erlang systems stay up
schedulersone per core (12 here)reductionspreempt after ~4,000 function callsprocessesown heap, own GC, mailboxper-process GCno stop-the-world pausesdirty schedulersfor long native work
swipe the figure sideways, or tap expand for full screen
1/4
schedulers
The BEAM runs one scheduler thread per core (System.schedulers_online() reported 12 here), each with a run queue of processes, and balances them across cores.
one scheduler per core12 on this machine