Por que escrevi um livro sobre o BEAM (a VM do Erlang)

• A experiência prática de manter os sistemas centrais da Klarna mostrou que uma interrupção de 15 milissegundos no BEAM podia provocar falhas de pagamento em larga escala e respostas emergenciais
• O livro foi escrito ao longo de 10 anos com o objetivo de criar uma referência confiável sobre o BEAM
• Durante a escrita, houve frustrações e recomeços repetidos, incluindo troca de editora, problemas técnicos e várias reorganizações da estrutura
• Após virar open source, o feedback da comunidade, a participação, o aumento de estrelas e o incentivo contínuo passaram a servir como motivação constante
• O conteúdo central se concentra na estrutura e operação da VM BEAM, com uma composição pensada para ajudar engenheiros na prática

---

Motivação para escrever o livro sobre o BEAM

Post-mortems, café e 10 anos de obstinação

• Ao operar o sistema central de pagamentos da Klarna, ele viveu repetidamente situações em que apenas 15 milissegundos de parada do BEAM levavam a milhões de falhas de pagamento, reuniões de emergência na madrugada e até chamadas do CEO
• Sempre fez falta um material que permitisse resolver essas crises rapidamente, e The BEAM Book foi escrito com o desejo de que o próximo engenheiro consiga resolver o problema mais depressa

Processo inicial de escrita

Começo e frustração

• Em outubro de 2012, o projeto começou com um único arquivo DocBook e grandes ambições
• Os commits de duas semanas se concentraram principalmente em trabalho estrutural e atualização de metadados; o conteúdo real era muito pouco
• Em novembro, houve migração para AsciiDoc e scripts de build personalizados, com expectativa de concluir tudo em 6 meses, mas o progresso foi muito lento por causa de reescritas e mudanças de estrutura contínuas

Colaboração com editoras

• Em 2013, foi assinado um contrato com a O’Reilly e houve migração para o Atlassian Atlas, mas continuaram ocorrendo problemas com perda de arquivos e gerenciamento de capítulos
• O histórico do Git ficou marcado por uma sequência de insatisfações e correções estruturais
• Em março de 2015, foram tentadas soluções de último recurso, como forçar a separação por capítulos apenas para conseguir passar no build
• Dois meses depois, o contrato foi encerrado discretamente, trazendo ao mesmo tempo abatimento e alívio
• Uma segunda tentativa com a Pragmatic Bookshelf também acabou interrompida após um avanço lento

Reset e participação da comunidade

• Em janeiro de 2017, todo o conteúdo foi transferido para um novo repositório em um massive commit (6.622 arquivos, 1 milhão de linhas), mas a reescrita também ficou estagnada
• Em março de 2017, o trabalho recomeçou em um repositório privado no GitHub baseado em Asciidoctor, copiando apenas as partes necessárias
• Duas semanas depois, o projeto foi tornado público e colaboradores externos passaram a corrigir typos, adicionar diagramas e colaborar com a licença de forma ativa

Fatores de motivação contínua

• No fundo, a maior força motriz era a curiosidade pessoal e o desejo de entender como o BEAM realmente funciona
• O feedback e as sugestões da comunidade aumentaram a vontade de continuar escrevendo, e o crescimento no número de estrelas no GitHub serviu como motivação constante
• Issues de incentivo, como “Please continue being awesome”, também tiveram um papel importante de apoio psicológico
• O fato de o livro passar a ser citado com frequência em eventos acadêmicos e conferências ligados a Erlang e BEAM ajudou a comprovar sua necessidade
• Menções e compartilhamentos contínuos no Twitter e em outros espaços também estimularam a continuidade da escrita

Estrutura do livro e principais leitores

• O conteúdo foi escrito com foco nas partes que eram realmente indispensáveis ao projetar e operar grandes sistemas em Erlang
  • Escalonadores e gerenciamento de processos: princípios de escalonamento de processos, prioridade e balanceamento sob carga real
  • Memória de processos: heap, stack, mensagens, gerenciamento de binários e seu impacto na operação
  • Coleta de lixo e modelo de memória: funcionamento do GC por processo/global, vazamentos de memória e estruturas de referência
  • Sistema de representação de dados: estrutura interna de tagging de dados como inteiros, floats, tuplas e binários
  • Compilador e estrutura interna da VM: fluxo real de execução de instruções na VM após a compilação
  • Tracing e depuração: dbg, erlang:trace, rastreamento de mensagens e eventos
  • Ajuste de desempenho: profiling de código real, análise de causas de latência e compreensão de reductions
  • Arquitetura de sistemas: princípios de funcionamento integrado do ERTS, da VM BEAM e de seus subsistemas
• O livro tem impacto bastante prático para profissionais que operam Erlang/Elixir no dia a dia, e seu objetivo central é servir como um guia abrangente e confiável no lugar de materiais dispersos

Lições aprendidas durante a escrita

• Persistência vence o perfeccionismo. Mesmo após duas experiências de cancelamento editorial, a conclusão foi que isso ainda é melhor do que deixar a obra “inacabada”
• Foco e definição de limites são essenciais. Reservar tempo para escrever, bloquear notificações e manter uma gestão rígida do tempo foram as verdadeiras fontes de progresso
• Abertura e feedback são centrais para a melhoria qualitativa. Correções externas, incentivo e estímulo constante ajudaram muito
• Gerenciar o escopo é indispensável. Ao ajustar o escopo, temas difíceis como Dirty Scheduler e JIT foram deixados para apêndices futuros
• A estratégia de melhorar iterativamente após o lançamento é importante. O BEAM muda todos os anos, e um repositório Git vivo permite aperfeiçoamento contínuo
• Definir um prazo real foi um grande motivador. O prazo de imprimir o livro antes do evento Code Beam Stockholm ajudou a selecionar o conteúdo realmente essencial

Definição de conclusão

• Foi apenas no momento de segurar a cópia impressa nas mãos que finalmente surgiu a sensação de “conclusão”
• Como commits dispersos passaram a estar reunidos em um único volume concreto, decidiu-se declarar o trabalho encerrado no estado atual

Como participar

• The BEAM Book 1.0 atualmente pode ser comprado em versão impressa na Amazon
  • Link da Amazon
• Se você encontrar typos ou pontos de melhoria, ou tiver curiosidade sobre a estrutura interna, pode usar star, fork, abertura de issue e pull request no repositório do GitHub
  • Contribuidores são mencionados nominalmente nos agradecimentos
  • GitHub: theBeamBook
• Como avaliações reais pesam mais no algoritmo, resenhas também são fortemente incentivadas
• Também é possível realizar workshops de internals do BEAM focados em sistemas reais; para contato, envie um e-mail para [e-mail]

[GN⁺]

Comentários do Hacker News

• O repositório git pode ser visto aqui

• Achei marcante a motivação do autor de continuar se aprofundando porque queria entender o BEAM de verdade. Acho que esse tipo de paixão produz resultados excelentes. Por isso decidi comprar na hora. Falando da minha experiência, já recebi várias propostas de editoras para escrever livros, mas nunca deu certo porque o que elas queriam e o que eu queria eram diferentes. Por exemplo, eu não queria escrever um livro introdutório de Java para jovens de 14 anos, e a editora não tinha interesse nos temas em que eu gosto de me aprofundar (por exemplo, classloader). Fico curioso para saber como outras pessoas encontram a interseção entre paixão pessoal e a necessidade dos leitores

  • Pela minha experiência de ter escrito três livros, ou você faz autopublicação ou escreve o livro que a editora quer. Cada editora tem um estilo próprio, e muitas se concentram em livros práticos para iniciantes, então, se você quer escrever sobre um tema pouco popular, o caminho mais realista é se preparar para autopublicar. Felizmente, hoje em dia a autopublicação ficou mais fácil e também é possível vender online. Em outras palavras, se for um tema bem de nicho, a realidade é que não dá para esperar por uma editora; você mesmo precisa cuidar da publicação e da divulgação
  • Se você tem algo interessante a dizer, no fim os leitores vão encontrar um jeito de entender. No início da minha carreira, li “Essential .Net”, do Don Box, e também não parecia um livro voltado para um público específico. Era simplesmente um livro que se aprofundava no CLR, e para entender tudo de verdade na primeira vez era preciso ler várias vezes
  • Fico pensando se é mesmo necessário depender de uma editora, ou se dá para escrever um livro de forma independente. Queria entender se é pela marca da editora ou por algum benefício adicional
  • Concordo que ensinar é a melhor forma de aprender. Aprendi isso dando aulas particulares de matemática no ensino médio, e a experiência de escrever um livro é parecida. É a melhor forma de transformar o conteúdo em algo realmente seu, indo além de uma compreensão superficial
  • Parece meio exibido dizer isso, mas eu também acabei escrevendo um livro sobre treinamento de força para escalada depois de me aprofundar tanto no tema. Originalmente eu ia autopublicar, mas no fim procurei uma editora e fiz algumas mudanças para deixá-lo um pouco mais fácil de ler. Abordar diretamente uma editora também pode ser um caminho

• Trabalhar com BEAM e Erlang/OTP foi uma das melhores experiências de desenvolvimento que tive no último ano. Usei o livro “Programming Erlang: Software for a Concurrent World”, do Joe Armstrong, e quero recomendá-lo fortemente para iniciantes. “Designing for Scalability with Erlang/OTP” também é bem avaliado, mas ainda não comecei. Em profundidade, porém, este livro novo é muito superior. O BEAM realmente parece uma tecnologia alienígena deixada por uma civilização antiga. O livro saiu na hora certa e comprei imediatamente. Impressiona que o Dr. Erik Stenman tenha concluído o livro mesmo depois de a publicação ter sido cancelada duas vezes

  • Fiquei curioso para saber que tipo de software você desenvolveu com BEAM/Erlang/OTP

• Elixir e BEAM são minha escolha favorita para construir sistemas baseados em rede ou com muitos pipelines. Usei diariamente em produção por vários anos, e, embora a escolha não seja tão simples nos projetos recentes, continuo acompanhando de perto. Sou grato pelo lançamento deste livro. Era exatamente o tipo de livro que eu queria ter anos atrás, quando estava depurando Elixir em produção. O material que existia era complicado demais ou simples demais

• Informações sobre o BEAM (Erlang virtual machine) podem ser vistas no link da Wikipédia

  • O próprio título do livro já explica bem

• Acho que o BEAM é uma das tecnologias mais subestimadas do mundo open source. Um exemplo é o WhatsApp. É um mistério para mim por que Elixir e Erlang não são mais populares em projetos de alta concorrência

  • Meu trabalho é numa empresa especializada em Erlang. O verdadeiro valor do Erlang aparece em tráfego de grande escala, como milhões de DAU. Dá para rodar um site com alguns milhares de DAU em Elixir, mas a essência do Erlang e do BEAM está nessa escala. Não são tantas empresas que precisam disso, e um problema ainda maior é que o ecossistema de Erlang funciona quase como um sistema operacional separado, então a configuração do ambiente e dos componentes pode ser bem complexa. Você não precisa de outras tecnologias de infraestrutura, como contêineres ou k8s, e justamente por causa do jeito próprio do Erlang isso pode parecer pouco familiar. Quando você usa Erlang numa situação em que ele encaixa perfeitamente, parece mágica. Foi um dos pontos altos da minha carreira
  • No fim, acho que é efeito de marketing. Java, C# e Go têm apoio corporativo fortíssimo, enquanto Erlang ou é prejudicado pelas próprias empresas ligadas a ele ou simplesmente não recebe muita atenção fora da documentação técnica. Elixir foi a primeira vez que houve uma tentativa de seguir um marketing mais parecido com o de outras linguagens (no estilo Ruby), mas o momento e o contexto eram diferentes. Acho que os desenvolvedores conseguem reconhecer as qualidades do BEAM, mas ele não convence tão bem outros tomadores de decisão
  • Acho que a diferença de investimento é grande. Rust, Go, Python e outras receberam muito investimento corporativo em análise estática, checagem de tipos, experiência do desenvolvedor etc., enquanto Erlang não recebeu esse mesmo carinho, e até os grandes usuários estão aos poucos construindo soluções fora do BEAM ou migrando
  • Recentemente trocamos nosso site no Squarespace por uma aplicação Phoenix, e foi uma experiência muito prazerosa
  • Ao mesmo tempo, é o “ingrediente secreto” menos secreto de todos. Recentemente a BBC também migrou para Elixir, então sinto que a popularidade está aumentando aos poucos

• Gostei da explicação de que “Erlang Runtime System (ERS)” é um termo genérico para o runtime de Erlang, enquanto “Erlang RunTime System (ERTS)” se refere especificamente à implementação da Ericsson

  • Acho que essa definição não é boba

• Comprei o livro na hora. Dá para ler de graça online, mas quis apoiar o autor nem que fosse um pouco

• Não trabalho com sistemas gigantes como o da Klarna, então é difícil ter referência, mas acho curioso que um atraso de 15 ms vire tema de postmortem

  • No BEAM, respostas em microssegundos (μs) são comuns, então, se começar a ir para milissegundos (ms), isso pode disparar alertas imediatamente
  • Em sistemas BEAM, isso pode acontecer tranquilamente. Se você cria um gen_server para proteger um estado compartilhado, isso funciona como um mutex gigante. Se o gen_server leva 20 μs para processar uma requisição, um atraso de 15 ms significa 750 mensagens acumuladas na fila. Se além disso a fila de mensagens estiver sendo usada com um padrão ineficiente, o desempenho despenca. O BEAM só otimiza a fila de mensagens para certos padrões específicos; nos demais, o tempo de processamento cresce conforme o tamanho da fila. Se uma biblioteca usa receive de forma insegura internamente, isso pode causar degradação de desempenho inesperada. Recentemente o BEAM adicionou o recurso alias para amenizar problemas de fila de mensagens, mas muitas bibliotecas ainda não o utilizam. O objetivo do alias é evitar perda de mensagens e impedir que mensagens de timeout poluam a fila. Em geral, processos de longa duração processam a fila em loop
  • Se alguém souber o link do postmortem do caso mencionado, eu queria ver. Não consegui encontrar online

• Fico curioso para saber se existe alguma VM semelhante ao BEAM. Será que não existem concorrentes porque o BEAM é bom demais, ou porque é difícil demais construir algo assim?

  • Acho que a infraestrutura moderna de Kubernetes oferece funções parecidas com as do BEAM. Hoje em dia é possível implementar sistemas de self-healing em larga escala com esse tipo de infraestrutura, sem ficar preso a uma linguagem específica. Além de Erlang/Elixir, existem muitos outros ecossistemas, profissionais e interesses
  • Existe também o AtomVM, uma implementação separada para dispositivos com recursos limitados, como IoT. Houve muitas tentativas de implementar o BEAM ou o OTP em outros ecossistemas, mas a maioria não chegou ao nível da VM
  • Quando surgiu, no fim dos anos 1990 e começo dos 2000, o BEAM era bastante singular. Hoje ainda dá para resolver muito bem os mesmos problemas com várias linguagens e ferramentas, só com abordagens diferentes. Também existe uma atitude típica de parte da comunidade Erlang de achar que “o jeito BEAM é o único certo”, mas em 2025 realmente há muitas opções. Existem implementações compatíveis com o BEAM, mas a maioria é de nicho. Se não for necessário entrar numa infraestrutura BEAM já existente, acho que soluções mais modernas do ecossistema atual fazem mais sentido para projetos greenfield. Há também projetos pequenos como o ergo
  • A Dis VM provavelmente é a mais parecida, e depois dela a VM do Smalltalk. Na prática, mais do que o próprio BEAM, é o OTP por cima dele que faz o BEAM mostrar seu verdadeiro valor
  • Em uso prático, a coisa mais parecida provavelmente é Go. O BEAM é um ecossistema ajustado para “linguagens do tipo Erlang”, então Elixir e Gleam também têm um comportamento central parecido com Erlang. Go oferece primitivas no estilo Erlang para concorrência, como goroutines, mas não tem uma visão tão definida sobre a estrutura da aplicação quanto o OTP