Warum ich ein Buch über die BEAM (Erlang VM) geschrieben habe

• Aus praktischen Erfahrungen bei der Wartung der Kernsysteme von Klarna führte ein 15-Millisekunden-Aussetzer der BEAM zu großflächigen Zahlungsausfällen und Notfallmaßnahmen
• Um eine verlässliche Referenz zur BEAM zu schaffen, schrieb ich das Buch über einen Zeitraum von 10 Jahren
• Während des Schreibprozesses erlebte ich wiederholt Rückschläge und neue Anläufe, darunter Verlagswechsel, technische Probleme und mehrfache strukturelle Überarbeitungen
• Nach der Open-Source-Veröffentlichung dienten Feedback aus der Community, Beteiligung, mehr Stars und Ermutigung als kontinuierliche Motivation
• Der Kerninhalt konzentriert sich auf Aufbau und Betrieb der BEAM VM und ist so zusammengestellt, dass er praktischen Nutzen für Ingenieurinnen und Ingenieure bietet

---

Motivation für das Schreiben des BEAM-Buchs

Post-Mortems, Kaffee und 10 Jahre Beharrlichkeit

• Beim Betrieb eines zentralen Zahlungssystems bei Klarna erlebte ich wiederholt, wie ein nur 15 Millisekunden langer Aussetzer der BEAM zu Millionen fehlgeschlagener Zahlungen, nächtlichen Krisensitzungen und sogar Anrufen vom CEO führte
• Dass es keine Unterlagen gab, mit denen sich solche Krisen schnell lösen lassen, war immer frustrierend, und mit dem Wunsch, dass die nächste Ingenieurin oder der nächste Ingenieur Probleme schneller beheben kann, schrieb ich The BEAM Book

Der frühe Schreibprozess

Anfang und Rückschläge

• Im Oktober 2012 begann das Projekt mit einer einzigen DocBook-Datei und großen Ambitionen
• Die Commits der ersten zwei Wochen konzentrierten sich überwiegend auf Strukturarbeit und das Aktualisieren von Metadaten; echter Inhalt war kaum vorhanden
• Im November wechselte ich zu AsciiDoc und einem benutzerdefinierten Build-Skript und hoffte auf eine Fertigstellung innerhalb von sechs Monaten, doch durch ständiges Umschreiben und Strukturänderungen ging es nur sehr langsam voran

Zusammenarbeit mit Verlagen

• Nach dem Verlagsvertrag mit O’Reilly im Jahr 2013 migrierte ich zu Atlassian Atlas, doch Probleme wie Dateiverluste und Schwierigkeiten bei der Kapitelverwaltung traten weiterhin auf
• Die Git-Historie ist geprägt von Unzufriedenheit und fortlaufenden Strukturkorrekturen
• Im März 2015 griff ich zu Notmaßnahmen wie der erzwungenen Aufteilung nach Kapiteln, einzig mit dem Ziel, den Build durchzubekommen
• Zwei Monate später wurde der Vertrag stillschweigend beendet, was gleichzeitig Selbstzweifel und Erleichterung auslöste
• Auch der zweite Versuch mit dem Pragmatic Bookshelf wurde wegen langsamer Fortschritte wieder eingestellt

Reset und Beteiligung der Community

• Im Januar 2017 wurde das gesamte Projekt mit einem massive commit in ein neues Repository übertragen (6.622 Dateien, 1 Million Zeilen), doch auch das Umschreiben geriet ins Stocken
• Im März 2017 begann ich erneut in einem privaten GitHub-Repository auf Basis von Asciidoctor und kopierte nur die tatsächlich benötigten Teile
• Zwei Wochen später wurde das Repository öffentlich, und sofort folgten Korrekturen von Tippfehlern, neue Diagramme und Unterstützung bei der Lizenzierung durch externe Mitwirkende

Faktoren für dauerhafte Motivation

• Der größte Antrieb war im Kern die persönliche Neugier und der Wunsch, die echte Funktionsweise der BEAM zu verstehen
• Feedback und Vorschläge aus der Community stärkten den Willen weiterzuschreiben, und die steigende Zahl an GitHub-Stars wirkte dauerhaft motivierend
• Ermutigende Issues wie „Please continue being awesome“ spielten auch als psychologische Unterstützung eine große Rolle
• Dass das Buch in Konferenzen und Fachveranstaltungen rund um Erlang und BEAM immer häufiger zitiert wurde, bestätigte seine Notwendigkeit
• Auch fortlaufende Erwähnungen und Shares auf Twitter und anderswo spornten das Weiterschreiben an

Struktur des Buchs und wichtigste Zielgruppe

• Beschrieben werden vor allem die Themen, die ich beim Entwurf und Betrieb großer Erlang-Systeme selbst unbedingt gebraucht hätte
  • Scheduler und Prozessverwaltung: Prozess-Scheduling unter realer Last, Prioritäten und Lastverteilungsprinzipien
  • Prozessspeicher: Heap, Stack, Nachrichten, Binary-Verwaltung und deren Auswirkungen auf den Betrieb
  • Garbage Collection und Speichermodell: Funktionsweise prozessbezogener/globaler GC, Speicherlecks und Referenzstrukturen
  • Datenrepräsentation: interne Tagging-Strukturen von Integern, Fließkommazahlen, Tupeln, Binaries und anderen Daten
  • Compiler und interne VM-Struktur: tatsächlicher Ablauf der Befehlsausführung in der VM nach dem Kompilieren
  • Tracing und Debugging: dbg, erlang:trace, Verfolgung von Nachrichten und Ereignissen usw.
  • Performance-Tuning: Profiling von echtem Code, Analyse von Latenzursachen, Verständnis von reduction
  • Systemarchitektur: integrierte Funktionsweise von ERTS, BEAM VM und Subsystemen
• Für praktisch arbeitende Erlang-/Elixir-Betreiberinnen und -Betreiber hat es einen sehr konkreten Nutzen und soll vor allem als verlässlicher, umfassender Leitfaden statt verstreuter Einzelquellen dienen

Lehren aus dem Schreibprozess

• Beharrlichkeit schlägt Perfektionismus. Selbst zwei gescheiterte Verlagsanläufe sind besser als „unvollendet“
• Fokus und Grenzziehung sind wichtig. Reservierte Schreibzeit, das Abschalten von Benachrichtigungen und strenges Zeitmanagement waren die eigentliche Quelle des Fortschritts
• Öffentlichkeit und Feedback sind zentral für qualitative Verbesserung. Externes Korrekturlesen, Ermutigung und kontinuierliche Impulse halfen enorm
• Scope-Management ist unverzichtbar. Durch das Anpassen des Umfangs wurden schwierige Themen wie Dirty Scheduler und JIT auf spätere Anhänge verschoben
• Eine Strategie aus Release und anschließender iterativer Verbesserung ist wichtig. Die BEAM verändert sich jedes Jahr, und als lebendes Git-Repository lässt sich das Buch fortlaufend ergänzen
• Eine echte Deadline ist ein wirksamer Motivator. Der Drucktermin vor der Veranstaltung Code Beam Stockholm zwang dazu, die wirklich wichtigen Inhalte auszuwählen

Was Vollendung bedeutet

• In dem Moment, in dem ich das tatsächliche gedruckte Buch in den Händen hielt, hatte ich endlich das Gefühl, dass es „vollendet“ ist
• Die verstreuten Commits sind zu einem greifbaren Buch zusammengefasst, daher erkläre ich es aus heutiger Sicht für abgeschlossen

Wie man mitmachen kann

• The BEAM Book 1.0 ist derzeit als Taschenbuch bei Amazon erhältlich
  • Amazon-Link
• Wer Tippfehler oder Verbesserungsmöglichkeiten entdeckt oder sich für die interne Struktur interessiert, kann im GitHub-Repository Stars vergeben, forken, Issues anlegen und Pull Requests einreichen
  • Mitwirkende werden im Dankesabschnitt namentlich erwähnt
  • GitHub: theBeamBook
• Da echte Rezensionen vom Algorithmus stärker gewichtet werden, wird auch aktiv um Bewertungen gebeten
• Zudem sind Workshops zu den BEAM internals mit Fokus auf reale Systeme möglich; Anfragen bitte per E-Mail an [e-mail]

[GN⁺]

Hacker-News-Kommentare

• Das git-Repository ist hier zu finden.

• Beeindruckend ist die Motivation des Autors, immer tiefer zu graben, weil er BEAM wirklich verstehen wollte. Ich denke, genau solche Leidenschaft führt zu großartigen Ergebnissen. Deshalb habe ich sofort beschlossen, das Buch zu kaufen. Aus meiner eigenen Erfahrung: Ich habe mehrfach Angebote von Verlagen bekommen, Bücher zu schreiben, aber es kam nie dazu, weil unsere Vorstellungen zu unterschiedlich waren. Zum Beispiel wollte ich kein Java-Einsteigerbuch für 14-Jährige schreiben, und die Verlage hatten kein Interesse an den Themen, in die ich mich tief eingrabe, etwa classloader. Mich interessiert, wie andere die Schnittmenge zwischen persönlicher Leidenschaft und den Bedürfnissen der Leser finden.

  • Nach meiner Erfahrung mit drei geschriebenen Büchern gibt es im Grunde zwei Wege: Self-Publishing oder ein Buch schreiben, das der Verlag haben möchte. Jeder Verlag verfolgt seinen eigenen Stil, und viele konzentrieren sich auf praktische Einsteigerbücher. Wenn man also über ein nicht massentaugliches Thema schreiben will, ist Self-Publishing der realistische Weg. Zum Glück ist das heute einfacher geworden, und man kann auch online verkaufen. Die Realität ist also: Wenn man ein Thema für einen sehr kleinen Nischenmarkt schreiben will, sollte man nicht auf einen Verlag hoffen, sondern Veröffentlichung und Vermarktung selbst übernehmen.
  • Wenn man selbst etwas Interessantes zu sagen hat, werden Leser am Ende einen Weg finden, es zu verstehen. Früh in meiner Laufbahn habe ich Don Box’ „Essential .Net“ gelesen, und auch das wirkte nicht so, als sei es gezielt für ein bestimmtes Publikum geschrieben worden. Es war einfach ein Buch, das tief in das Innenleben der CLR eintauchte, und man musste es mehrfach lesen, um es anfangs vollständig zu verstehen.
  • Ich frage mich, ob man wirklich auf einen Verlag angewiesen ist oder ob man problemlos unabhängig selbst ein Buch schreiben kann. Ob es um den Namen des Verlags geht oder um zusätzliche Vorteile?
  • Ich stimme zu, dass Lehren die beste Methode zum Lernen ist. Das habe ich schon als Mathe-Nachhilfelehrer in der Highschool gelernt, und das Schreiben eines Buches ist ähnlich. Es ist die beste Methode, über bloßes Verstehen hinauszugehen und sich die Grundlagen wirklich zu eigen zu machen.
  • Das klingt vielleicht ein bisschen nach Angeberei, aber ich habe auf diese Weise auch ein Buch über Krafttraining fürs Klettern geschrieben, nachdem ich mich tief in das Thema eingearbeitet hatte. Ursprünglich wollte ich es selbst veröffentlichen, aber am Ende habe ich doch einen Verlag gefunden und es etwas zugänglicher überarbeitet. Man kann also auch direkt auf Verlage zugehen.

• Die Arbeit mit BEAM und Erlang/OTP war eine meiner besten Entwicklungserfahrungen im letzten Jahr. Ich habe dafür Joe Armstrongs Buch „Programming Erlang: Software for a Concurrent World“ verwendet und würde es Einsteigern sehr empfehlen. „Designing for Scalability with Erlang/OTP“ hat ebenfalls einen guten Ruf, aber ich habe noch nicht damit angefangen. In Sachen Tiefe ist dieses Buch hier jedoch überwältigend. BEAM wirkt wirklich wie eine außerirdische Technologie, die eine antike Zivilisation hinterlassen hat. Perfektes Timing für dieses Buch, also sofort gekauft. Ich bin beeindruckt, dass Dr. Erik Stenman es trotz zweier abgesagter Veröffentlichungen fertiggestellt hat.

  • Mich würde interessieren, welche Art von Software du mit BEAM/Erlang/OTP entwickelt hast.

• Elixir und BEAM sind meine bevorzugte Wahl für Systeme mit starkem Netzwerkbezug oder vielen Pipelines. Ich habe sie mehrere Jahre täglich in Produktion verwendet, und auch wenn die Wahl im aktuellen Projekt nicht einfach ist, verfolge ich die Entwicklungen weiterhin aufmerksam. Danke für die Veröffentlichung dieses Buches. So ein Buch hätte ich mir vor einigen Jahren beim Debuggen von Elixir in Produktion unbedingt gewünscht. Das vorhandene Material war entweder zu schwierig oder umgekehrt zu oberflächlich.

• Informationen zu BEAM (Erlang virtual machine) gibt es im Wikipedia-Artikel.

  • Im Buchtitel selbst ist es bereits gut erklärt.

• Ich halte BEAM für eine der am stärksten unterschätzten Technologien im Open-Source-Bereich. Ein Beispiel ist WhatsApp. Es ist mir ein Rätsel, warum Elixir und Erlang bei Projekten mit hoher Nebenläufigkeit nicht populärer sind.

  • Meine Firma ist ein auf Erlang spezialisiertes Unternehmen. Die wahre Stärke von Erlang zeigt sich bei sehr großem Traffic, etwa Millionen von DAU. Man kann mit Elixir auch Websites mit einigen Tausend DAU betreiben, aber das Wesen von Erlang und BEAM liegt in diesem Maßstab. Nicht viele Unternehmen brauchen so eine Größenordnung, und das größere Problem ist, dass das Erlang-Ökosystem selbst fast wie ein eigenes OS funktioniert, wodurch Setup und Komponenten ziemlich komplex werden. Andere Infrastrukturtechnologien wie Container oder k8s braucht man nicht unbedingt, und gerade wegen der Eigenheiten von Erlang wirkt das oft ungewohnt. Wenn man Erlang in einer Situation erlebt, in der es perfekt passt, fühlt es sich wie Magie an. Für mich war das ein Karriere-Highlight.
  • Ich denke, am Ende ist es eine Frage des Marketings. Java, C# und Go haben starke Unternehmensunterstützung, während Erlang eher dadurch gebremst wird, dass sich Unternehmen kaum darum kümmern oder nur technische Dokumentation liefern. Elixir war die erste Sprache, die eher ein anderes Sprach-Marketingmodell verfolgt hat, nämlich das Ruby-Modell, aber der Zeitpunkt und die Umstände waren anders. Entwickler lassen sich wohl von den Vorzügen von BEAM überzeugen, aber bei anderen Entscheidungsträgern verfängt das nicht so gut.
  • Ich denke, der Unterschied bei den Investitionen ist groß. In Rust, Go, Python usw. wurde durch Unternehmensunterstützung stark in statische Analyse, Type Checking und Developer Experience investiert, während Erlang nicht annähernd dieselbe Aufmerksamkeit bekommen hat, und selbst große Nutzer bauen zunehmend eigene Lösungen außerhalb von BEAM oder wechseln weg.
  • Wir haben vor Kurzem unsere Squarespace-Website durch eine Phoenix-Anwendung ersetzt, und das war eine wirklich schöne Erfahrung.
  • Gleichzeitig ist es die am wenigsten geheime „Geheimzutat“. Auch die BBC ist kürzlich auf Elixir umgestiegen, daher habe ich den Eindruck, dass es langsam populärer wird.

• Mir gefiel die Erklärung, dass „Erlang Runtime System (ERS)“ das allgemeine Erlang-Runtime bezeichnet, während „Erlang RunTime System (ERTS)“ auf die Ericsson-Implementierung beschränkt ist.

  • Ich finde diese Definition nicht dumm.

• Ich habe das Buch sofort gekauft. Man kann es kostenlos online lesen, aber ich wollte den Autor wenigstens ein wenig unterstützen.

• Ich arbeite nicht an großen Systemen wie Klarna, daher ist es schwer nachzuvollziehen, dass eine Verzögerung von 15 ms Thema einer Postmortem-Analyse wird.

  • In BEAM sind Antwortzeiten im Mikrosekundenbereich (μs) üblich, daher kann schon ein Ausschlag in den Millisekundenbereich (ms) sofort einen Alarm auslösen.
  • In BEAM-Systemen kommt so etwas durchaus vor. Wenn man zum Schutz von gemeinsamem Zustand einen gen_server baut, ist das im Grunde wie ein riesiger Mutex. Wenn ein gen_server 20 us für die Bearbeitung einer Anfrage braucht, bedeuten 15 ms Verzögerung, dass sich 750 Nachrichten in der Message Queue angesammelt haben. Nutzt man die Queue dann auch noch mit ineffizienten Mustern, bricht die Performance stark ein. BEAM optimiert die Message Queue nur für bestimmte Muster; bei anderen wächst die Verarbeitungszeit mit der Länge der Queue. Wenn intern in einer Bibliothek ein unsicheres receive verwendet wird, kann das zu unerwarteten Performance-Einbrüchen führen. Kürzlich hat BEAM die Funktion alias hinzugefügt, um Probleme mit Message Queues abzumildern, aber viele Bibliotheken nutzen sie noch nicht. alias dient dazu, Nachrichtenverluste zu verhindern und zu vermeiden, dass die Queue durch Timeout-Nachrichten verschmutzt wird. Normalerweise verarbeiten langlebige Prozesse die Queue in einer Schleife.
  • Falls jemand einen Link zum Postmortem des erwähnten Vorfalls hat, würde mich das interessieren. Ich konnte online nichts dazu finden.

• Ich frage mich, ob es ähnliche VMs wie BEAM gibt. Ist BEAM vielleicht einfach so gut, dass es keine Konkurrenz gibt, oder ist es einfach entsprechend schwer zu bauen?

  • Ich würde sagen, moderne Kubernetes-Infrastruktur bietet ähnliche Funktionen wie BEAM. Heute baut man mit solcher Infrastruktur großskalige selbstheilende Systeme, ohne an eine bestimmte Sprache gebunden zu sein. Neben Erlang/Elixir gibt es eben auch andere Ökosysteme, Fachkräfte und Interessenlagen.
  • Mit AtomVM gibt es auch eine separate Implementierung für eingeschränkte Geräte wie IoT-Hardware. Es gab viele Versuche, BEAM oder OTP in anderen Ökosystemen nachzubauen, aber meistens nicht auf VM-Ebene.
  • Als BEAM Ende der 90er und Anfang der 2000er entstand, war es ziemlich einzigartig. Heute lassen sich dieselben Probleme mit verschiedenen Sprachen und Werkzeugen gut lösen, nur mit anderen Implementierungsansätzen. In der Erlang-Community gibt es zwar manchmal die Haltung „Nur der BEAM-Weg ist richtig“, aber 2025 gibt es wirklich viele Optionen. Es gibt auch BEAM-kompatible Implementierungen, doch die meisten bedienen Nischen. Wenn man sich nicht in bestehende BEAM-Infrastruktur einklinken muss, halte ich für Greenfield-Projekte moderne Lösungen aus heutigen Ökosystemen für geeigneter. Es gibt auch kleinere Projekte wie ergo.
  • Dis VM ist wahrscheinlich am ähnlichsten, danach vielleicht die Smalltalk-VM. Eigentlich ist aber weniger BEAM selbst entscheidend, sondern OTP obendrauf, wodurch BEAM erst richtig zur Geltung kommt.
  • In der Praxis ist Go vermutlich am ähnlichsten. BEAM ist ein Ökosystem, das auf „Erlang-artige Sprachen“ zugeschnitten ist, daher funktionieren auch Elixir oder Gleam im Kern ähnlich wie Erlang. Go bietet mit Goroutines und ähnlichem nebenläufige Primitiven im Erlang-Stil, hat aber keine so klare Sicht auf die Struktur von Anwendungen wie OTP.