A essência do Erlang não está nos processos leves e na passagem de mensagens (2023)

Contexto

• Erlang é uma linguagem desenvolvida para construir sistemas distribuídos confiáveis; começou inicialmente como uma biblioteca de Prolog e evoluiu para uma linguagem independente.
• Foi usada na Ericsson para programar centrais telefônicas e, em 1998, tornou-se open source.
• Joe Armstrong foi um dos principais projetistas do Erlang, e sua tese de doutorado tratava de como criar sistemas distribuídos confiáveis na presença de falhas de software.

Behaviours

• Os behaviours do Erlang são semelhantes a interfaces em Java ou Go e consistem em um conjunto de assinaturas de tipo que pode ter várias implementações.
• Com behaviours, basta escrever apenas o código que define a lógica de negócio do programa, enquanto o código de infraestrutura é fornecido automaticamente.
• Os behaviours são escritos por especialistas e se baseiam em melhores práticas.

Behaviour de servidor genérico

• gen_server é explicado com o exemplo de implementação de um armazenamento chave-valor.
• handle_call é responsável por atualizar o estado ou consultar uma chave, e toda a concorrência fica oculta dentro do componente gen_server.

Behaviour de gerenciador de eventos

• gen_event é um gerenciador de eventos que registra manipuladores de eventos e os executa quando uma mensagem chega.
• É útil para registro de erros, e é fornecido um exemplo simples de logger.

Behaviour de máquina de estados

• gen_fsm teve seu nome alterado para gen_statem e é adequado para implementar protocolos.

Behaviour de supervisor

• O supervisor verifica se outros processos estão funcionando corretamente e, em caso de falha, os reinicia de acordo com uma estratégia predefinida.
• A estratégia one_for_one reinicia apenas o processo que falhou, enquanto a estratégia one_for_all reinicia todos os filhos quando um único processo falha.

Behaviours de aplicação e release

• Uma aplicação inclui a árvore de supervisão e tudo o que for necessário, enquanto um release empacota uma ou mais aplicações.
• Deve ser possível fazer rollback em caso de falha na atualização.

Implementação de behaviours

• Mais do que os processos leves e a passagem de mensagens do Erlang, é a estrutura dos behaviours que leva a software confiável.
• Para implementar behaviours em outras linguagens, é possível começar usando assinaturas de interface.

Correção dos behaviours

• Testes de simulação facilitam o teste de sistemas distribuídos, e a estrutura do behaviour gen_server pode simplificar a resolução de problemas.

Contribuição

• Há ideias como aproveitar o trabalho de Martin Thompson para criar um event loop rápido e adicionar I/O assíncrona.
• Se você tiver interesse, opiniões, sugestões ou perguntas, é possível entrar em contato.

[GN⁺]

Comentários no Hacker News

• O impressionante no Erlang e no BEAM é a profundidade de suas funcionalidades. Para o OP, o maior ganho foi a Behavior/Interface do Erlang. Pessoalmente, acho importante que os recursos de desenvolvimento necessários para construir sistemas complexos sejam muito menores do que em outras linguagens. Para muita gente, os processos leves e o modelo de programação são o grande atrativo

  • O OTP inclui uma enorme quantidade de funcionalidades. Estamos trabalhando para compilar o Elixir de modo que ele possa rodar em dispositivos iOS. Usando a biblioteca ei do Erlang, é possível compilar nós em C e fazer interface com outros nós Erlang. Por meio da biblioteca rpc do Erlang, é possível fazer chamadas de função em C e interagir com aplicações Elixir
  • O Erlang já resolveu muitos problemas com os quais as stacks tecnológicas modernas ainda lutam, além de ter resolvido questões de escalabilidade e custo de implementação décadas atrás. No entanto, no HN, o interesse por Erlang/Elixir não se converteu em adoção real, e muitas empresas desperdiçam dinheiro tentando implementar por conta própria o que a stack Erlang já oferece de graça

• Trabalhei com algumas pessoas, inclusive gestores, que queriam escrever livros com base na própria experiência. Sempre discordávamos sobre os fatores do sucesso. Algumas pessoas afirmam que processos leves e passagem de mensagens não são o ingrediente secreto, mas deixam passar que o Communicating Sequential Processes do Erlang é inseparável dessas características

  • Exemplo: o programador da aplicação escreve código sequencial, e toda a concorrência fica escondida nos behaviors
  • É fácil para novos integrantes entrarem no time: a lógica de negócio é sequencial e tem uma estrutura parecida com algo que eles talvez já tenham visto antes
  • Supervisores e a filosofia de "deixe falhar" contribuem para a criação de sistemas confiáveis

• Voltei a me interessar por Erlang por causa dos processos leves e da passagem de mensagens. Até agora, os behaviors eram algo secundário

  • O projeto é levar programação visual Flow Based Programming (FBP) para Erlang. O FBP parece combinar bem com Erlang, e foi surpreendente descobrir que isso já existia
  • Estamos usando o Node-RED como ferramenta de FBP, e a ideia básica é conectar o frontend do Node-RED a um backend em Erlang e transformar todos os nós em processos

• Eu estava procurando informações sobre por que a Ericsson deixou de usar Erlang e sobre a demissão do Joe

  • A resposta curta é que Erlang foi sendo deixado de lado à medida que novos projetos migravam para Java. Joe e seus colegas fundaram a Bluetail em 1998, e ela foi adquirida pela Nortel. A Nortel era uma gigante de telecomunicações: suas ações chegaram a $125 em 2000, mas caíram para menos de $1 em 2002. Isso esteve ligado ao estouro da bolha das pontocom e à redução dos gastos em telecomunicações

• A força do Erlang/Elixir não está na implementação do modelo Actor, no matching do Prolog, na imutabilidade ou nos behaviors, mas no desejo do Joe de mostrar que é possível fazer mais com menos recursos

  • É um sistema bem projetado e coerente, com um nível de consistência raramente visto em outras linguagens. Não é perfeito, mas é impressionante
  • Acho que ainda falta, no mundo do software, percepção e aceitação do poder da simplicidade

• Erlang, OTP e BEAM oferecem muito mais do que behaviors. A VM se parece com um kernel virtual, oferecendo supervisores, processos isolados e modo distribuído. O OTP oferece módulos úteis como Mnesia (banco de dados), contadores atômicos/tabelas ETS (cache) etc.

  • Há um ano, uma consultoria individual adotou Erlang como linguagem de backend. Exploramos o interior do BEAM para substituir a stack baseada em TCP por QUIC e integrar patches em Rust

• O conceito mais interessante em Erlang/BEAM é que a recuperação parcial já vem embutida por padrão. Quando surge um estado inesperado, em vez de encerrar o processo inteiro ou correr o risco de causar corrupção, faz-se rollback para um estado conhecido e bom no nível mais granular possível

• O motivo pelo qual a estrutura de behaviors do Erlang não é copiada por outras linguagens e por designers de bibliotecas é que as assinaturas das funções dos behaviors em Erlang estão intimamente ligadas a outras características da linguagem, especialmente seu uso peculiar de imutabilidade

  • Para alcançar o mesmo objetivo em outras linguagens, não se deve copiar diretamente a forma do Erlang. Recomendo aprender com a forma como Erlang produz software confiável, mas sou fortemente contra portar esse modo de fazer literalmente para outras linguagens

• Não concordo com o conteúdo deste texto. Os behaviors são possíveis graças à arquitetura básica do sistema. Behaviors não são interfaces, mas algo mais parecido com objetos abstratos em linguagens como Java

  • O artigo do Joe mostra como construir sistemas confiáveis usando um conjunto específico de blocos de Lego

• Behaviors não são tão interessantes. Eles existem em outras linguagens de programação também. O interessante no BEAM é que lançar erros é algo feito de forma muito elegante. A combinação entre lançar erros e o poder dos behaviors facilita capturar erros, relatar informações de contexto e, em geral, compor tudo isso de maneira flexível