Por qué escribí un libro sobre BEAM (la VM de Erlang)

• A partir de la experiencia real manteniendo sistemas críticos de Klarna, una pausa de 15 milisegundos en BEAM provocó fallas masivas de pago y respuestas de emergencia
• Escribí el libro durante 10 años para crear una referencia confiable sobre BEAM
• Durante la escritura pasé por frustraciones repetidas y nuevos intentos, incluyendo cambios de editorial, problemas técnicos y varias reestructuraciones
• Tras hacerlo open source, el feedback de la comunidad, la participación, el aumento de estrellas y el apoyo constante sirvieron como motivación continua
• El contenido central se enfoca en la estructura y operación de la VM BEAM, con una organización pensada para ayudar de forma práctica a ingenieros de producción

---

Motivación para escribir el libro de BEAM

Post-mortems, café y 10 años de obsesión

• Mientras operaba sistemas de pago críticos en Klarna, viví repetidamente situaciones en las que apenas 15 milisegundos de pausa en BEAM derivaban en millones de pagos fallidos, reuniones de emergencia de madrugada e incluso llamados del CEO
• Siempre lamenté la falta de material que permitiera resolver esas crisis con rapidez, y escribí The BEAM Book con la esperanza de que el siguiente ingeniero pudiera resolver el problema más rápido

Primeras etapas de escritura

Inicio y frustración

• En octubre de 2012, inicié el proyecto con un solo archivo de DocBook y grandes aspiraciones
• Durante dos semanas, la mayoría de los commits se concentraron en la estructura y en actualizar metadatos; el contenido real era muy poco
• En noviembre cambié a AsciiDoc y scripts de build personalizados y esperaba terminarlo en seis meses, pero el progreso fue muy lento debido a reescrituras constantes y cambios de estructura

Colaboración con editoriales

• En 2013 firmé un contrato de publicación con O’Reilly y migré a Atlassian Atlas, pero siguieron ocurriendo pérdidas de archivos y problemas para gestionar los capítulos
• El historial de Git está marcado por una sucesión de quejas y ajustes estructurales
• En marzo de 2015 probé soluciones de último recurso, como dividir capítulos a la fuerza solo para lograr que el build pasara
• Dos meses después, el contrato se canceló silenciosamente, lo que me dejó sintiendo a la vez alivio y autodesprecio
• Un segundo intento con Pragmatic Bookshelf también se detuvo tras avanzar lentamente

Reinicio y participación de la comunidad

• En enero de 2017, toda la base se trasladó a un nuevo repositorio mediante un massive commit (6622 archivos, 1 millón de líneas), pero la reescritura volvió a estancarse
• En marzo de 2017 empecé otra vez en un repositorio privado de GitHub basado en Asciidoctor, copiando solo lo necesario
• Dos semanas después, al hacerlo público, comenzaron activamente las correcciones de typos, la adición de diagramas y la colaboración con la licencia por parte de contribuyentes externos

Factores de motivación sostenida

• En esencia, el mayor motor fue la curiosidad personal y el deseo de comprender cómo funciona realmente BEAM
• El feedback y las sugerencias de la comunidad reforzaron la voluntad de seguir escribiendo, y el aumento del número de estrellas en GitHub funcionó como motivación continua
• Los issues de apoyo, como “Please continue being awesome”, también cumplieron un papel importante como respaldo psicológico
• El hecho de que el libro se citara cada vez más en simposios y conferencias sobre Erlang y BEAM demostró la necesidad de su existencia
• Las menciones y compartidos constantes en Twitter y otros lugares también impulsaron a seguir escribiendo

Estructura del libro y lectores principales

• Está escrito principalmente alrededor de los puntos que realmente necesitaba mientras diseñaba y operaba sistemas Erlang a gran escala
  • Schedulers y gestión de procesos: principios de scheduling de procesos, prioridades y balanceo bajo carga real
  • Memoria de procesos: heap, stack, mensajes, manejo de binarios y su impacto operativo
  • Garbage collection y modelo de memoria: funcionamiento del GC por proceso/global, fugas de memoria y estructuras de referencia
  • Sistema de representación de datos: estructura interna de tags para enteros, flotantes, tuplas, binarios y otros datos
  • Compilador y estructura interna de la VM: flujo real de ejecución de instrucciones dentro de la VM después de compilar
  • Tracing y debugging: dbg, erlang:trace, rastreo de mensajes y eventos, etc.
  • Ajuste de rendimiento: profiling de código real, análisis de causas de latencia y cómo entender las reductions
  • Arquitectura del sistema: principios de funcionamiento integrado de ERTS, la VM BEAM y sus subsistemas
• Busca tener un impacto muy práctico para operadores e ingenieros que trabajan con Erlang/Elixir, y su objetivo central es servir como una guía integral y confiable en lugar de materiales dispersos

Lecciones del proceso de escritura

• La persistencia vence al perfeccionismo. Incluso después de dos cancelaciones editoriales, la conclusión fue que eso sigue siendo mejor que dejarlo “inconcluso”
• La concentración y los límites son importantes. Asegurar tiempo para escribir, bloquear notificaciones y gestionar el tiempo con rigor fueron la fuente del progreso real
• La apertura y el feedback son claves para mejorar la calidad. La corrección externa, el apoyo y el estímulo constante ayudaron mucho
• La gestión del alcance es indispensable. Al ajustar el alcance, temas difíciles como Dirty Scheduler y JIT se dejaron para apéndices futuros
• La estrategia de mejorar iterativamente después del release es importante. BEAM cambia cada año, y un repositorio Git vivo permite seguir refinándolo
• Fijar una fecha límite real fue una motivación concreta. La meta de tenerlo impreso antes del evento Code Beam Stockholm obligó a seleccionar lo esencial

Qué significa estar terminado

• Solo al tener la edición impresa en las manos pude sentir por fin que estaba “terminado”
• Los commits dispersos quedaron reunidos en un solo objeto tangible, y desde el punto de vista actual eso permite declarar el final

Cómo participar

• The BEAM Book 1.0 ya puede comprarse en formato impreso en Amazon
  • Enlace de Amazon
• Si encuentras typos o mejoras, o si tienes curiosidad por la estructura interna, puedes usar las stars, forks, issues y pull requests del repositorio en GitHub
  • Los contribuidores serán mencionados por su nombre real en los agradecimientos
  • GitHub: theBeamBook
• Como las reseñas reales pesan más en el algoritmo, también se piden activamente comentarios y reseñas
• También es posible impartir un taller de internals de BEAM centrado en sistemas reales; para consultas, escribe a [e-mail]

[GN⁺]

Opinión de Hacker News

• El repositorio de git se puede ver aquí

• Me llamó la atención la motivación del autor: seguir profundizando porque quería entender bien BEAM. Creo que esa clase de pasión produce grandes resultados. Por eso decidí comprarlo de inmediato. En mi caso, varias editoriales me propusieron escribir libros, pero nunca se concretó porque queríamos cosas distintas. Por ejemplo, yo no quería escribir una introducción a Java para jóvenes de 14 años, y a las editoriales no les interesaban los temas en los que yo profundizo, como los classloader. Me da curiosidad cómo encuentran otros esa intersección entre la pasión personal y lo que necesitan los lectores

  • Por mi experiencia escribiendo tres libros, al final hay dos caminos: autopublicar o escribir el libro que quiere la editorial. Cada editorial tiene su propio perfil y muchas se enfocan en manuales prácticos para principiantes, así que si quieres escribir sobre temas poco populares, lo realista es prepararte para autopublicar. Por suerte, hoy eso es más fácil y también se puede vender en línea. En otras palabras, si apuntas a un tema muy de nicho, no esperes una editorial: te toca encargarte tú mismo de la publicación y la promoción
  • Si cuentas algo que de verdad te parece interesante, al final los lectores encontrarán la forma de entenderlo. Al inicio de mi carrera leí “Essential .Net” de Don Box, y tampoco parecía un libro dirigido a un público específico. Simplemente era un libro que profundizaba en el interior del CLR, y para entenderlo por completo al principio había que leerlo varias veces
  • Me pregunto si realmente hace falta depender de una editorial o si uno puede escribir un libro de forma independiente. Tengo curiosidad por saber si es por el nombre de la editorial o por otros beneficios adicionales
  • Estoy de acuerdo en que enseñar es una de las mejores formas de aprender. Lo comprobé en la preparatoria dando tutorías de matemáticas, y escribir un libro se parece mucho a eso. Es la mejor forma de ir más allá de una comprensión superficial y apropiarte de los fundamentos
  • Suena un poco presumido, pero a mí también me pasó algo parecido: terminé escribiendo un libro sobre entrenamiento de fuerza para escalada después de meterme tanto en el tema. Al principio pensaba autopublicarlo, pero al final encontré una editorial e hice algunos cambios para que fuera un poco más fácil de leer. También puede servir acercarse directamente a una editorial

• Trabajar con BEAM y Erlang/OTP ha sido una de mis mejores experiencias de desarrollo en el último año. Usé el libro “Programming Erlang: Software for a Concurrent World” de Joe Armstrong, y me gustaría recomendarlo mucho a quienes van empezando. “Designing for Scalability with Erlang/OTP” también tiene muy buena fama, aunque todavía no lo he empezado. Pero en cuanto a profundidad, este libro nuevo está a otro nivel. BEAM de verdad parece una tecnología alienígena dejada por una civilización antigua. El libro llegó en un gran momento, así que lo compré de inmediato. Me impresiona que el Dr. Erik Stenman lo haya terminado incluso después de que su publicación se cancelara dos veces

  • Tengo curiosidad por saber qué tipo de software desarrollaste con BEAM/Erlang/OTP

• Elixir y BEAM son mi opción favorita para construir sistemas basados en red o con muchos pipelines. Los usé a diario durante años en producción, y aunque en proyectos recientes la elección ya no es tan obvia, sigo de cerca todo lo que pasa. Agradezco que este libro haya salido. Hace unos años, mientras depuraba Elixir en producción, era justo el tipo de libro que quería tener. El material existente me parecía o demasiado difícil o demasiado simplificado

• Se puede consultar información sobre BEAM (Erlang virtual machine) en este enlace de Wikipedia

  • El título del libro ya lo explica bastante bien

• Creo que BEAM es una de las tecnologías más infravaloradas del mundo open source. WhatsApp es un buen ejemplo. Me parece un misterio que Elixir y Erlang no sean más populares para proyectos con alta concurrencia

  • En mi trabajo somos una empresa especializada en Erlang. El verdadero valor de Erlang aparece con tráfico a gran escala, como millones de DAU. Puedes correr un sitio web en Elixir con miles de DAU, pero la esencia de Erlang y BEAM está en esa otra escala. No hay tantas empresas que necesiten eso y, además, un problema mayor es que el ecosistema de Erlang funciona casi como un sistema operativo aparte, así que la configuración del entorno y de sus componentes es bastante compleja. Ni siquiera hacen falta otras tecnologías de infraestructura como contenedores o k8s, y justamente por esa forma propia de hacer las cosas Erlang puede sentirse poco familiar. Pero cuando lo usas en el contexto adecuado, Erlang se siente como magia. Ha sido uno de los puntos más altos de mi carrera
  • Creo que al final es una cuestión de marketing. Java, C# y Go tienen detrás un respaldo corporativo enorme, mientras que con Erlang las empresas más bien lo frenan o apenas le prestan atención fuera de la documentación técnica. Elixir fue el primero en seguir una forma de marketing más parecida a la de otros lenguajes, como el modelo de Ruby, pero llegó en un momento y un contexto distintos. Los desarrolladores probablemente entienden lo bueno que es BEAM, pero parece que no logra convencer tan bien a quienes toman decisiones fuera de ese círculo
  • Creo que la diferencia en inversión es enorme. Rust, Go y Python, entre otros, han recibido mucha inversión corporativa en análisis estático, type checking, experiencia de desarrollo y más, mientras que Erlang no ha recibido ese mismo nivel de cariño, y hasta sus grandes usuarios poco a poco han terminado construyendo soluciones por fuera de BEAM o migrando a otra cosa
  • Hace poco convertimos un sitio de Squarespace a una aplicación Phoenix y fue una experiencia realmente agradable
  • Al mismo tiempo, es el “ingrediente secreto” menos secreto de todos. Hace poco la BBC también migró a Elixir, así que siento que poco a poco está ganando popularidad

• Me gustó la explicación de que “Erlang Runtime System (ERS)” se refiere al runtime genérico de Erlang, mientras que “Erlang RunTime System (ERTS)” es un término limitado a la implementación de Ericsson

  • No me parece una definición tonta

• Compré el libro de inmediato. Se puede leer gratis en línea, pero quise apoyar aunque sea un poco al autor

• No trabajo con sistemas enormes como Klarna, así que me cuesta dimensionarlo, pero me sorprende que una latencia de 15 ms llegue a ser tema de un postmortem

  • En BEAM, respuestas en microsegundos (μs) son lo normal, así que si algo se va a milisegundos (ms), puede disparar alertas de inmediato
  • En sistemas BEAM esto puede pasar perfectamente. Si creas un gen_server para proteger estado compartido, eso funciona como un mutex enorme. Si ese gen_server tarda 20us en procesar una solicitud, una demora de 15ms significa que se acumularon 750 mensajes en la cola. Y si además usas la cola de mensajes con patrones ineficientes, el rendimiento cae muchísimo. BEAM solo optimiza ciertos patrones de cola; en los demás casos, el tiempo de procesamiento crece según la longitud de la cola. Si dentro de una librería se usa un receive inseguro, pueden aparecer degradaciones de rendimiento inesperadas. Hace poco BEAM añadió la función alias para mitigar problemas de colas de mensajes, pero muchas librerías todavía no la usan. alias busca evitar la pérdida de mensajes y también impide que la cola se contamine con mensajes de timeout. Normalmente, los procesos de larga vida procesan la cola en un bucle
  • Si alguien tiene el enlace al postmortem de ese incidente, me interesa verlo. No pude encontrarlo en línea

• Me pregunto si existe alguna VM similar a BEAM. Quisiera saber si no tiene competencia porque es demasiado buena, o si simplemente es tan difícil de construir

  • Yo diría que la infraestructura moderna de Kubernetes ofrece capacidades parecidas a las de BEAM. Hoy en día se pueden construir sistemas self-healing a gran escala con ese tipo de infraestructura, sin restricciones de lenguaje. También existen otros ecosistemas, más talento disponible y otros intereses aparte de Erlang/Elixir
  • También está AtomVM, que es una implementación aparte para dispositivos limitados como los de IoT. Ha habido muchos intentos de implementar BEAM u OTP en otros ecosistemas, pero la mayoría no llegan al nivel de la VM
  • En la época en que apareció, a finales de los 90 e inicios de los 2000, BEAM sí era bastante único. Hoy el mismo tipo de problemas se puede resolver bien con muchos lenguajes y herramientas, aunque se implementen distinto. También existe cierta actitud dentro de la comunidad Erlang de que “la forma BEAM es la única correcta”, pero en 2025 realmente hay muchísimas opciones. Hay implementaciones compatibles con BEAM, aunque en general son de nicho. Si no necesitas integrarte a infraestructura BEAM existente, para un proyecto greenfield creo que hoy suelen encajar mejor soluciones modernas del ecosistema actual. También hay proyectos pequeños como ergo
  • La Dis VM probablemente es la más parecida, y después vendría la VM de Smalltalk. En realidad, más que BEAM por sí solo, es OTP encima de BEAM lo que hace que destaque de verdad
  • En uso práctico, lo más parecido probablemente sea Go. BEAM está pensado para un ecosistema de “lenguajes tipo Erlang”, así que en Elixir o Gleam el comportamiento central se parece mucho al de Erlang. Go ofrece primitivas de concurrencia al estilo Erlang, como las goroutines, pero no tiene una visión tan clara sobre la estructura de la aplicación como la que ofrece OTP