Uma (muito) breve história do Erlang

Apesar de ter sido lançado em 1986 (apenas dois anos depois que este escritor nasci), só conheci Erlang por volta de 2017. Como desenvolvedor de aplicativos web, entrei em contato com ele da mesma forma que provavelmente aconteceu com a maioria das pessoas: RabbitMQ. Naquela época, estávamos usando o RabbitMQ em um projeto que tinha um processo de ETL. Precisávamos de velocidade, concorrência e bloqueio seguro de registros. Mais tarde, descobri que a razão pela qual o RabbitMQ conseguia isso era o fato de ter sido escrito especificamente em Erlang para atender a esses requisitos.

Considerando que foi classificado como o segundo maior salário médio em 2025, o que exatamente é isso e quais são seus casos de uso específicos?

A paisagem

O ponto de partida para qualquer história é identificar onde está a lacuna. O PHP surgiu como uma ferramenta de script para criar dinamicamente páginas HTML, JavaScript começou como LiveScript para permitir um ambiente de execução dentro do navegador. Desde aqueles dias em 1995, ambas as linguagens evoluíram totalmente a níveis irreconhecíveis devido à natureza de suas necessidades. De maneira semelhante, o Erlang foi criado especificamente para o setor de comunicações. Naquela época, o setor de telecomunicações precisava de um código capaz de lidar com escalabilidade massiva, concorrência ultra-alta e execução em tempo real. Seu surgimento teve origem no desenvolvimento do switch ATM AXD301, criado pela Ericsson, que exigia o que é conhecido como disponibilidade de “nove noves”. Em termos leigos, trata-se de um switch de hardware cujo software exige uma taxa de disponibilidade de 99,9999999%. Não existia, na época, uma linguagem de programação capaz de atender a essa exigência.

Evolução

O Erlang realmente começou a ganhar força quando a Ericsson decidiu tornar a linguagem como código aberto em dezembro de 1998. A linguagem foi lançada e, com ela, surgiram projetos externos. A partir desse momento, foram surgindo gradualmente materiais que traçavam as linhas gerais sobre como usar essa linguagem e quais eram seus principais casos de uso.

“Deixe-o cair”

Let it burn!OK, aqui vai um conceito inovador para você: você é incentivado a deixar os processos falharem. Venho de um lugar onde a programação defensiva é absolutamente essencial para a criação de Applications. É nesse ponto que “eu entendo”, porque o Erlang não foi projetado como uma linguagem clássica de back-end baseada em servidor. A razão pela qual falhas são aceitáveis é que os desenvolvedores são incentivados a escrever código em pequenos blocos que podem ser executados isoladamente. A execução do aplicativo deve ser feita por sistemas supervisores que, então, procuram threads ou processos que tenham travado, os quais são reiniciados. É essa filosofia que resulta em alta disponibilidade: não importa se uma tarefa não foi concluída, basta que os dados necessários sejam transmitidos em algum momento. Foi assim que o Erlang passou a ser tão predominante nos mercados verticais de comunicações: a resiliência que ele proporciona é a razão pela qual o RabbitMQ, um cliente de mensagens, é escrito em Erlang. Isso também explica por que o WhatsApp, da Meta, é escrito em Erlang, ou por que o popular aplicativo de mensagens Discord é escrito em Elixir (uma versão ligeiramente modificada do Erlang que ainda roda na VM BEAM), e, de fato, por que eu já tinha algum conhecimento prévio sobre os casos de uso do Erlang, já que a Vonage é uma Plataforma de Comunicação como Serviço (CPaaS).

Concorrência

Como ele consegue lidar com esse nível de concorrência? Desenvolvedores tradicionais de aplicativos web talvez já tenham se deparado com sistemas Async/Promise, como, por exemplo, em C# ou no Node.js. Não é assim que o Erlang funciona: em vez de threads do sistema operacional, ele possui sua própria máquina virtual (VM), chamada BEAM, que lida com processos individuais leves. Como o BEAM consegue alternar entre eles (de forma semelhante à forma como os PHP Fibers proporcionaram concorrência) na velocidade da luz, ele consegue lidar com milhões desses processos ao mesmo tempo.

Veja como isso se quebra

A tolerância a falhas que mencionei anteriormente é gerenciada por árvores de supervisão. Esse padrão de projeto interno faz parte do núcleo da Open Telecom Platform do Erlang — pense nele como o equivalente à biblioteca padrão. Existe uma rede de supervisores que monitora os processos, o que ressalta a importância de os desenvolvedores considerarem o reinício dos processos em vez de tentarem o tratamento de erros no estilo tradicional “try-catch”.

À prova de falhas: Troca a quente

Às vezes, recursos que eu nunca tinha visto antes em linguagens de programação realmente me impressionam; lembro-me de ter descoberto que era possível aplicar um “monkeypatch” no núcleo da linguagem Ruby em tempo de execução, algo que eu simplesmente não conseguia entender. Semelhante a essa descoberta: lembra que a tolerância a falhas está no cerne do Erlang? Pois bem, quando o Erlang está em execução, é possível trocar código em tempo real sem parar a VM. Se você já se perguntou como o WhatsApp consegue enviar uma enxurrada de atualizações com tempo de inatividade aparentemente nulo, essa é a resposta.

Conclusão

Basicamente, abordamos a filosofia fundamental que moldou o Erlang como ele é hoje. Com base nisso, a linguagem se torna a escolha ideal não apenas para mensagens e comunicações, mas também para qualquer outra aplicação que exija o mesmo nível de disponibilidade e tolerância a falhas. Ela também se mostra muito útil quando utilizada em bancos de dados, o que explicaria por que tanto o CouchDB e Riak sejam escritos em Erlang. Portanto, para os desenvolvedores ambiciosos que estão pensando em criar seu próprio backend de IoT ou talvez buscando integrar APIs de rede à sua pilha de tecnologias, adoraríamos saber no que vocês estão trabalhando.

Leitura complementar

Documentação para desenvolvedores sobre APIs de rede

Documentação do Erlang