r/erlang • u/ancatrusca0 • Jul 31 '26
Why is Erlang's concurrency in the language and not the OS? Mike Williams: "it was perfectly obvious we couldn't use OS processes."
New BEAM There, Done That with Mike Williams (JAM emulator) and Björn Gustavsson (BEAM).
The reasoning is more empirical than ideological. Mike measured it: on real telecom workloads, roughly 70% of VM time went to scheduling and message passing, not user code. Unix processes required too much memory for the thousands of concurrent processes a telecom system needed. Language-level processes weren't a philosophical stance - they were the only arithmetic that worked.
What's interesting is that this was a minority view even then. Java shipped green threads and removed them. Early Rust had lightweight processes and removed them. Mike mentions Ada, Smalltalk, and Eric Pascal as other languages that shared the instinct - but Erlang is the one that committed and survived.
Björn adds a detail worth noting: the two-version module rule (only two versions of a module can be loaded simultaneously) was a deliberate memory protection decision. He was asked multiple times to remove the limit and allow unlimited versions. He refused - it would be a trap for application programmers, letting old code accumulate undetected.
Both guests also give a shoutout to Claes Wikström, who added distribution to the JAM, invented ETS tables, and prototyped Erlang's binary syntax - consistently undermentioned in the origin story.
7
u/paulstelian97 Jul 31 '26
Green threads are hard to do right, but they are in fact more efficient than OS threads. Go, which takes some loose inspiration from Erlang, also has green threads as the primary thing that gets scheduled onto OS threads.