Pourquoi j’ai écrit un livre sur BEAM (la VM d’Erlang)

• En maintenant les systèmes critiques de Klarna, j’ai vécu des incidents bien réels où 15 millisecondes d’arrêt de BEAM provoquaient des pannes de paiement massives et des interventions d’urgence
• J’ai écrit ce livre pendant 10 ans afin de créer une référence fiable sur BEAM
• Au cours de l’écriture, j’ai traversé des frustrations et des relances répétées : changement d’éditeur, problèmes techniques, multiples refontes de structure
• Après le passage en open source, les retours de la communauté, la participation, l’augmentation du nombre d’étoiles et les encouragements ont joué un rôle de motivation durable
• Le contenu se concentre sur la structure et le fonctionnement de la VM BEAM, avec une approche réellement utile pour les ingénieurs de terrain

---

Motivation pour écrire un livre sur BEAM

Post-mortems, café et 10 ans d’obsession

• En exploitant le système de paiement central de Klarna, j’ai vécu à plusieurs reprises des situations où un arrêt de seulement 15 millisecondes de BEAM entraînait des millions d’échecs de paiement, des réunions d’urgence en pleine nuit, jusqu’à des appels du CEO
• L’absence de ressources permettant de résoudre rapidement ce type de crise a toujours été frustrante, et c’est avec l’espoir que l’ingénieur suivant puisse aller plus vite que j’ai écrit The BEAM Book

Les débuts de l’écriture

Commencement et découragement

• En octobre 2012, le projet a démarré avec un simple fichier DocBook et de grandes ambitions
• Pendant deux semaines, les commits ont surtout porté sur la structure et les mises à jour de métadonnées, avec très peu de contenu réel
• En novembre, je suis passé à AsciiDoc et à des scripts de build personnalisés en pensant finir en six mois, mais les réécritures incessantes et les changements de structure ont fortement ralenti l’avancement

Collaboration avec les éditeurs

• En 2013, j’ai signé un contrat d’édition avec O’Reilly puis migré vers Atlassian Atlas, mais j’ai continué à subir des pertes de fichiers et des problèmes de gestion des chapitres
• L’historique Git est rempli de mécontentement et de corrections structurelles successives
• En mars 2015, j’ai tenté des solutions de fortune, comme forcer une séparation par chapitre uniquement pour faire passer le build
• Deux mois plus tard, le contrat a été résilié discrètement, provoquant à la fois un sentiment d’abattement et de soulagement
• Une deuxième tentative avec Pragmatic Bookshelf a elle aussi été abandonnée après une progression trop lente

Réinitialisation et participation de la communauté

• En janvier 2017, l’ensemble a été transféré vers un nouveau dépôt via un massive commit (6622 fichiers, 1 million de lignes), mais la réécriture est elle aussi restée bloquée
• En mars 2017, j’ai recommencé depuis un dépôt GitHub privé basé sur Asciidoctor, en ne recopiant que les parties nécessaires
• Deux semaines plus tard, le projet est devenu public, et les contributeurs externes se sont immédiatement activés : corrections de typos, ajout de diagrammes, collaboration sur la licence

Les moteurs de motivation sur la durée

• Au fond, le principal moteur était ma curiosité personnelle et mon désir de comprendre le fonctionnement réel de BEAM
• Les retours et suggestions de la communauté ont renforcé ma volonté de continuer, et l’augmentation du nombre d’étoiles sur GitHub a eu un effet de motivation durable
• Des issues d’encouragement comme « Please continue being awesome » ont aussi joué un rôle de soutien psychologique important
• Le fait que le livre soit de plus en plus cité dans des séminaires et conférences liés à Erlang et à BEAM a confirmé son utilité
• Les mentions et partages continus sur Twitter et ailleurs ont également stimulé la poursuite de l’écriture

Structure du livre et lecteurs visés

• Le livre se concentre avant tout sur les éléments qui m’ont semblé indispensables en concevant et en exploitant moi-même de grands systèmes Erlang
  • Ordonnanceur et gestion des processus : principes de planification, priorités et équilibrage des processus sous charge réelle
  • Mémoire des processus : heap, stack, messages, gestion des binaires et impact sur l’exploitation
  • Garbage collection et modèle mémoire : fonctionnement du GC par processus et global, fuites mémoire et structures de référence
  • Représentation des données : structure interne de marquage pour les entiers, flottants, tuples, binaires, etc.
  • Compilateur et structure interne de la VM : déroulement réel de l’exécution des instructions dans la VM après la compilation
  • Tracing et débogage : dbg, erlang:trace, suivi des messages et des événements, etc.
  • Tuning des performances : profiling sur du vrai code, analyse des causes de latence, compréhension des reductions
  • Architecture système : principes de fonctionnement intégrés d’ERTS, de la VM BEAM et des sous-systèmes
• L’objectif central est d’avoir un impact très concret pour les praticiens Erlang/Elixir en production, en servant de guide de référence fiable à la place de ressources éparpillées

Leçons tirées du processus d’écriture

• La persévérance l’emporte sur le perfectionnisme. Même après deux annulations éditoriales, il vaut mieux arriver à quelque chose que rester dans l’inachevé
• La concentration et la pose de limites sont essentielles. Réserver du temps pour écrire, couper les notifications et gérer son temps strictement sont la vraie source des progrès
• La publication et les retours sont au cœur de l’amélioration qualitative. Relectures externes, encouragements et stimulation régulière ont été d’une grande aide
• La gestion du périmètre est indispensable. En ajustant la portée, certains sujets difficiles (Dirty Scheduler, JIT, etc.) ont été reportés à de futures annexes
• La stratégie d’amélioration itérative après la release est importante. BEAM évolue chaque année, et un dépôt Git vivant permet de continuer à enrichir le contenu
• Se fixer une vraie deadline est une motivation concrète. L’objectif d’imprimer le livre avant l’événement Code Beam Stockholm a aidé à sélectionner l’essentiel

Définir ce qu’est “terminé”

• C’est au moment de tenir la version imprimée entre mes mains que j’ai enfin eu le sentiment que c’était terminé
• Des commits épars se sont matérialisés en un véritable livre, ce qui me permet, pour l’instant, de déclarer le projet achevé

Comment participer

• The BEAM Book 1.0 peut actuellement être acheté en version papier sur Amazon
  • Lien Amazon
• Si vous repérez des typos, des améliorations possibles, ou si vous êtes curieux de la structure interne, vous pouvez utiliser le star, fork, issue et pull request du dépôt GitHub
  • Les contributeurs seront mentionnés nominativement dans les remerciements
  • GitHub: theBeamBook
• Les avis comptant davantage dans l’algorithme, les critiques et commentaires sont aussi vivement encouragés
• Un atelier sur les internals de BEAM centré sur les systèmes en production peut également être proposé ; pour toute demande, écrire à [e-mail]

[GN⁺]

Commentaires sur Hacker News

• Le dépôt git est disponible ici

• J’ai été marqué par la motivation de l’auteur, qui continue de creuser simplement parce qu’il veut vraiment comprendre BEAM. Je pense que c’est ce genre de passion qui produit de superbes résultats. Du coup, achat immédiat. Pour parler de mon expérience, on m’a proposé plusieurs fois d’écrire un livre via des maisons d’édition, mais cela n’a jamais abouti parce que nous ne voulions pas la même chose. Par exemple, je n’avais aucune envie d’écrire une introduction à Java pour des ados de 14 ans, et les éditeurs ne s’intéressaient pas aux sujets que j’aime explorer en profondeur, comme les classloaders. Je me demande comment les autres trouvent l’intersection entre leur passion personnelle et les besoins des lecteurs

  • Après avoir écrit trois livres, j’ai l’impression qu’il n’y a que deux options : l’autoédition, ou écrire le livre que veut l’éditeur. Chaque maison d’édition a sa propre ligne éditoriale, et beaucoup se concentrent sur des ouvrages pratiques pour débutants ; si l’on veut écrire sur un sujet peu grand public, il est plus réaliste de se préparer à l’autoédition. Heureusement, c’est plus facile aujourd’hui et on peut aussi vendre en ligne. En clair, si le sujet vise un marché très de niche, il ne faut pas compter sur un éditeur et il faut assumer soi-même l’édition et la promotion
  • Si quelqu’un raconte quelque chose d’intéressant, les lecteurs finissent par trouver un moyen de le comprendre. Au début de ma carrière, j’ai lu “Essential .Net” de Don Box, et je n’ai pas eu l’impression qu’il visait un lectorat précis. C’était simplement un livre qui explorait en profondeur les entrailles du CLR, et il fallait le relire plusieurs fois pour vraiment le comprendre au départ
  • Je me demande s’il faut vraiment dépendre d’un éditeur, ou si l’on peut tout simplement écrire un livre de manière indépendante. Est-ce pour le nom de l’éditeur ou pour les avantages annexes ?
  • Je suis d’accord sur le fait qu’enseigner est la meilleure manière d’apprendre. Je l’ai constaté en donnant des cours particuliers de maths au lycée, et écrire un livre ressemble beaucoup à cela. C’est la meilleure façon non seulement de comprendre, mais de s’approprier les fondements en profondeur
  • C’est un peu prétentieux de le dire, mais moi aussi j’ai fini par écrire un livre de renforcement musculaire pour l’escalade après avoir creusé le sujet de cette manière. Au départ, je voulais l’autoéditer, mais j’ai finalement trouvé un éditeur et je l’ai légèrement remanié pour le rendre plus accessible. Contacter directement des éditeurs peut aussi être une bonne approche

• Travailler avec BEAM et Erlang/OTP a été l’une de mes meilleures expériences de développement sur l’année écoulée. J’ai utilisé le livre “Programming Erlang: Software for a Concurrent World” de Joe Armstrong, et j’aimerais vraiment le recommander aux débutants. “Designing for Scalability with Erlang/OTP” a aussi bonne réputation, mais je n’ai pas encore commencé. En revanche, en matière de profondeur, ce nouveau livre est de très loin au-dessus. BEAM ressemble vraiment à une technologie extraterrestre laissée par une civilisation antique. Très bon timing pour la sortie de ce livre, je l’ai acheté immédiatement. Je suis admiratif qu’Erik Stenman soit allé au bout après deux annulations de publication

  • Je suis curieux : quel type de logiciel as-tu développé avec BEAM/Erlang/OTP ?

• Elixir et BEAM sont mon choix favori pour construire des systèmes orientés réseau ou avec beaucoup de pipelines. Je les ai utilisés tous les jours en production pendant plusieurs années, et même si le choix est plus difficile sur mes projets récents, je continue de suivre l’écosystème de près. Merci pour la publication de ce livre. C’est exactement le genre de livre que j’aurais voulu avoir il y a quelques années quand je faisais du débogage sur de l’Elixir en production. Les ressources existantes étaient soit trop ardues, soit au contraire trop simplistes

• On peut trouver des informations sur BEAM (Erlang virtual machine) via ce lien Wikipédia

  • C’est déjà très bien expliqué dans le titre du livre

• Je pense que BEAM est l’une des technologies les plus sous-estimées de l’open source. WhatsApp en est un bon exemple. C’est un mystère pour moi qu’Elixir et Erlang ne soient pas plus populaires pour les projets à forte concurrence

  • Mon entreprise est spécialisée en Erlang. La vraie force d’Erlang apparaît avec un trafic massif, du genre plusieurs millions de DAU. On peut faire tourner un site web à quelques milliers de DAU avec Elixir, mais l’essence d’Erlang et de BEAM est à cette échelle-là. Peu d’entreprises ont besoin d’un tel niveau, et le plus gros problème, c’est que l’écosystème Erlang fonctionne presque comme un OS à part entière, avec un environnement et des composants assez complexes à configurer. On n’a pas besoin d’autres technologies d’infrastructure comme les conteneurs ou k8s, et justement cette approche propre à Erlang peut sembler déroutante. Mais quand on rencontre une situation parfaitement adaptée à Erlang, cela ressemble à de la magie. C’est le sommet de ma carrière
  • Au final, je pense que c’est surtout une question de marketing. Java, C# et Go bénéficient d’un énorme soutien d’entreprise, alors qu’Erlang est plutôt freiné par les entreprises, ou bien simplement ignoré en dehors de la documentation technique. Elixir a été le premier à reprendre un marketing plus proche d’autres langages, sur le modèle de Ruby, mais le moment et le contexte étaient différents. Les développeurs reconnaîtront sans doute la qualité de BEAM, mais cela semble moins parler aux autres décideurs
  • Je pense que l’écart vient aussi de l’investissement. Rust, Go, Python et d’autres ont bénéficié de gros moyens venus des entreprises pour l’analyse statique, la vérification de types, l’expérience développeur, etc., alors que l’écosystème Erlang n’a pas reçu autant d’attention, et même ses grands utilisateurs finissent progressivement par construire des solutions hors de BEAM ou par migrer
  • Nous avons récemment remplacé notre site Squarespace par une application Phoenix, et cela a été une expérience extrêmement agréable
  • C’est en même temps le “secret sauce” le moins secret qui soit. La BBC a récemment migré vers Elixir, donc j’ai l’impression que sa popularité augmente peu à peu

• J’ai bien aimé l’explication selon laquelle “Erlang Runtime System (ERS)” désigne le runtime Erlang au sens général, tandis que “Erlang RunTime System (ERTS)” désigne spécifiquement l’implémentation d’Ericsson

  • Je ne trouve pas cette définition idiote

• J’ai acheté le livre immédiatement. On peut le lire gratuitement en ligne, mais je voulais quand même soutenir un peu l’auteur

• Je ne travaille pas sur un système massif comme Klarna, donc j’ai du mal à me représenter le sujet, mais je trouve fascinant qu’une latence de 15 ms puisse faire l’objet d’un post-mortem

  • Sur BEAM, des temps de réponse à l’échelle de la microseconde (μs) sont courants, donc quand on dérive vers les millisecondes (ms), cela peut déclencher une alerte immédiatement
  • Oui, ce genre de situation arrive tout à fait sur les systèmes BEAM. Si l’on crée un gen_server pour protéger un état partagé, cela revient à quelque chose comme un énorme mutex. Si un gen_server met 20 μs à traiter une requête, alors un retard de 15 ms signifie que 750 messages se sont empilés dans la file. Si, en plus, la file de messages est utilisée avec des patterns inefficaces, les performances chutent rapidement. BEAM n’optimise la file de messages que pour certains patterns précis ; dans les autres cas, le temps de traitement augmente avec la longueur de la file. Si une bibliothèque utilise un receive non sûr en interne, cela peut provoquer une dégradation de performance inattendue. Récemment, BEAM a ajouté la fonctionnalité 'alias' pour atténuer les problèmes de file de messages, mais beaucoup de bibliothèques ne l’utilisent pas encore. L’objectif principal d’alias est d’éviter la perte de messages, et cela empêche aussi la file d’être polluée par des messages de timeout. En général, les processus de longue durée traitent leur file en boucle
  • Si quelqu’un a un lien vers le post-mortem de l’incident évoqué, cela m’intéresse. Je n’ai rien trouvé en ligne

• Je me demande s’il existe des VM similaires à BEAM. Je voudrais savoir si c’est parce que BEAM est tellement excellent qu’il n’a pas de concurrent, ou si c’est simplement parce que c’est très difficile à construire

  • Je dirais que l’infrastructure Kubernetes moderne offre des fonctionnalités proches de celles de BEAM. Aujourd’hui, ce type d’infrastructure permet de construire à grande échelle des systèmes auto-réparateurs, sans être limité à un langage particulier. En dehors d’Erlang/Elixir, il existe aussi d’autres écosystèmes, d’autres profils et d’autres centres d’intérêt
  • Il existe aussi AtomVM, une implémentation distincte pour des appareils contraints comme ceux de l’IoT. Il y a eu beaucoup de tentatives pour reproduire BEAM ou OTP dans d’autres écosystèmes, mais la plupart ne se situaient pas au niveau de la VM
  • À la fin des années 1990 et au début des années 2000, BEAM était assez unique. Aujourd’hui, on peut résoudre les mêmes problèmes avec de nombreux langages et outils, même si l’implémentation diffère. Il existe aussi dans la communauté Erlang une forme d’attitude consistant à penser que seule la “manière BEAM” est la bonne, mais en 2025 il y a réellement beaucoup d’options. Il existe des implémentations compatibles BEAM, mais elles restent pour la plupart de niche. Si l’on n’a pas besoin de rejoindre une infrastructure BEAM existante, alors pour un projet greenfield, les solutions modernes de l’écosystème actuel me semblent souvent plus adaptées. Il y a aussi de petits projets comme ergo
  • La Dis VM est probablement ce qui s’en rapproche le plus, puis la VM Smalltalk. En réalité, BEAM révèle surtout sa vraie valeur lorsqu’il est utilisé avec OTP
  • En usage réel, ce qui s’en rapproche le plus est probablement Go. BEAM correspond à un écosystème pensé pour des “langages de type Erlang”, donc Elixir ou Gleam ont un fonctionnement de base similaire à Erlang. Go fournit des primitives de concurrence à la Erlang, comme les goroutines, mais sans la vision aussi nette d’OTP sur la structure des applications