09.10.2026 · Signal Titans Editorial

Joe Armstrong construiu o Erlang em torno de uma regra estranha: deixe quebrar. Seus famosos “nove noves” precisam de uma nota de rodapé.

Joe Armstrong sorrindo de boné em uma conferência, ao lado de um painel luminoso com um diagrama de árvore de supervisão mostrando um processo que quebrou e o nome dele.

A maioria dos conselhos de programação sobre erros se resume a uma palavra: prevenir. Validar a entrada, proteger o ponteiro, envolver a chamada. O conselho de Joe Armstrong, escrito em sua tese de doutorado de 2003, soa como o oposto: "Se você não consegue fazer o que quer fazer, morra. Deixe quebrar. Não programe de forma defensiva."

Ele não falava de código de hobby. Falava de como a Ericsson construía centrais telefônicas, máquinas que deveriam funcionar por anos a fio. A frase "let it crash" virou o slogan mais conhecido do Erlang e também um dos mais mal compreendidos. O mesmo vale para o número famoso associado a ela: nove noves de confiabilidade.

Uma máquina que nunca pode parar

Armstrong entrou no Laboratório de Ciência da Computação da Ericsson, em Estocolmo, em 1985. Seu chefe, Bjarne Däcker, lhe deu uma missão que Armstrong depois citou em sua história da linguagem: "resolver o problema de software da Ericsson". O objetivo do laboratório, como ele descreveu, era "oferecer uma forma melhor de programar aplicações de telefonia".

A telefonia era um alvo difícil. Uma única central precisa lidar com "dezenas ou centenas de milhares de transações simultâneas", escreveu Armstrong. Seu software tinha de ser alterado enquanto rodava, "sem perda de serviço". E uma regra vinha direto das centrais AXE da Ericsson: a falha de um processo "deveria influenciar apenas a transação imediatamente envolvida". Uma chamada com defeito não podia derrubar todas as outras junto com ela.

Quando Armstrong e seu colega Robert Virding perguntavam a pesquisadores em conferências o que acontecia se um de seus nós caísse, as respostas não eram animadoras. As respostas habituais, lembrou Armstrong, eram "o sistema não vai funcionar" ou "nosso modelo assume que não há falhas".

De um lento modelo em Smalltalk a uma nova linguagem

Armstrong modelou a telefonia primeiro em Smalltalk, mas "o Smalltalk era muito lento". Quando mostrou sua notação a um colega, Roger Skagervall, a resposta foi curta: "isso é um programa em Prolog". O Erlang começou, nas palavras de Armstrong, como "acrescentar concorrência ao Prolog", rodando como um interpretador escrito no próprio Prolog. O desenvolvimento começou em 1986.

Logo deixou de ser um projeto de uma pessoa só. Virding escreveu uma segunda implementação. Mike Williams encontrou os primeiros usuários internos em 1987 e mais tarde escreveu o emulador em C para a máquina virtual do Erlang. Williams também contribuiu com a ideia dos links entre processos, que Armstrong atribui ao "mecanismo de liberação dos antigos telefones analógicos". Esse detalhe importa: o núcleo do tratamento de erros do Erlang foi emprestado do hardware que ele deveria substituir.

O que "let it crash" realmente significa

Lido isoladamente, "let it crash" soa como licença para ignorar erros. A tese diz algo mais específico. Sua lista completa de slogans começa com "Deixe que outro processo faça a recuperação de erros." O modelo, explicou Armstrong, são dois computadores que vigiam um ao outro: "Usamos exatamente o mesmo método em Erlang, só que em vez de computadores usamos pares de processos."

Na prática, um processo trabalhador faz o serviço e um processo supervisor separado o vigia. Os processos do Erlang não compartilham memória, então um trabalhador que quebra não consegue corromper os vizinhos. Quando ele morre, o link leva a notícia ao supervisor, que o inicia de novo. O supervisor pode até ficar em outra máquina, porque, nas palavras de Armstrong, "não se pode construir um sistema tolerante a falhas se você tem apenas um computador".

A tese também traça uma linha que a maioria dos resumos pula. Se o programador "sabe o que fazer para corrigir a condição que causou a exceção, então isso não é um erro". Um arquivo ausente pode ser capturado e tratado onde acontece. A falha é reservada para os casos em que "o programador não sabe o que fazer", os estados inesperados em que o código defensivo tende a adivinhar e piorar as coisas. Armstrong também foi honesto sobre os limites: o isolamento entre processos, escreveu, "não é perfeito", e um processo ainda pode montar o equivalente a um ataque de negação de serviço contra outro.

O AXD301 e os nove noves

A ideia teve seu grande teste depois que o projeto AXE-N da Ericsson ruiu em dezembro de 1995, um evento que Armstrong chamou de "o evento mais importante da história do Erlang". O Erlang foi escolhido para o novo comutador ATM AXD301, construído por mais de 60 programadores Erlang e organizado em torno das "árvores de supervisão" do OTP. Um retrato do fim de 2001 contava cerca de 1,1 milhão de linhas de código Erlang.

É do AXD301 que vem a lenda. Armstrong escreveu que ele "alcançou uma confiabilidade de NOVE noves", o que dá cerca de 31 milissegundos de indisponibilidade por ano. O número vem sendo repetido desde então como uma propriedade do próprio Erlang.

As fontes contam uma história mais restrita. A própria tese de Armstrong admite que a única evidência de longo prazo era "uma apresentação de PowerPoint" em que um grande cliente relatava um sistema de 11 nós com 99,9999999%, "embora não tenha sido documentado como esses números foram obtidos". Mats Cronqvist, arquiteto de sistemas do AXD301, explicou depois que a British Telecom "alegava disponibilidade de serviço de nove noves integrada sobre cerca de 5 nós-ano". Ele também apontou que havia "muito mais C do que Erlang no sistema" e que Armstrong "não fazia parte da equipe do AXD 301". Chamou a alegação de "bastante falsa", mas acrescentou que, em comparação com sistemas semelhantes, o comutador "era surpreendentemente confiável". Ulf Wiger, que liderou o projeto do AXD301, confirmou que o número era um dado real de um cliente e disse que outras implantações ficavam "consistentemente acima de 99,999%".

Assim, a versão documentada é menos mágica, mas ainda impressionante: a disponibilidade relatada por um cliente para uma rede, e não uma lei medida da linguagem.

Proibido, depois libertado

O sucesso não protegeu o Erlang dentro da Ericsson. Em fevereiro de 1998, a Ericsson Radio Systems o proibiu para novos produtos. Um documento interno de política deu o motivo: uma "linguagem proprietária" significava um esforço contínuo para manter seu suporte e suas ferramentas. Däcker observou depois a ironia de que essa "chatice com o 'proprietário'" tornou possível liberar o Erlang como código aberto, o que a Ericsson fez em dezembro de 1998. Armstrong e a maior parte da equipe central saíram então para fundar uma startup, a Bluetail. Seu veredicto sobre a proibição: a Ericsson "fez a coisa certa (usar a tecnologia certa para o trabalho) pelas razões erradas".

O código aberto deu ao Erlang uma segunda vida. Em 2012, os engenheiros do WhatsApp escreveram em seu blog que o Erlang era peça-chave de sua infraestrutura e mostraram um único servidor com mais de 2 milhões de conexões TCP. Armstrong morreu em abril de 2019; a comunidade Erlang lembrou dele como o pai da linguagem.

A ideia que sobreviveu à central

Poucas equipes hoje constroem centrais telefônicas, mas muitas constroem sistemas que reiniciam serviços que falharam, isolam cargas de trabalho e aceitam que sempre haverá algo quebrado em algum lugar. A contribuição de Armstrong foi fazer dessa suposição o ponto de partida, e não algo pensado depois.

A pergunta útil que seu trabalho deixa não é "como impeço isso de falhar?". É: quando esta parte falhar, quem percebe e quem a traz de volta?