Gleam OTP – desenvolvimento de programas multicore tolerantes a falhas com base em atores

 (github.com/gleam-lang)
1 pontos por GN⁺ 2025-10-21 | 1 comentários | Compartilhar no WhatsApp
  • Gleam OTP oferece suporte ao desenvolvimento de programas com modelo de atores, com tolerância a falhas e desempenho multicore
  • Tem como características o foco em segurança de tipos completa e compatibilidade com Erlang OTP
  • Fornece recuperação de falhas e autocura por meio de supervisores
  • Oferece apenas parte dos recursos do Erlang/OTP, e estratégias adicionais de gerenciamento estão em desenvolvimento
  • Suporta diversos tipos de ator, como processos comuns, atores e supervisores

Visão geral do Gleam OTP

  • Gleam OTP é um poderoso framework de atores inspirado na arquitetura OTP do Erlang, adequado para implementar programas multicore tolerantes a falhas
  • É um projeto open source sob a licença Apache-2.0

Principais características e vantagens

  • Garante segurança de tipos completa para atores e mensagens
  • Oferece compatibilidade com Erlang OTP, facilitando a integração com ambientes Erlang já existentes
  • Dá suporte à tolerância a falhas por meio de supervisores (supervisor), com detecção de falhas, recuperação automática e gerenciamento de encerramento
  • Busca atingir o mesmo desempenho do Erlang OTP
  • A documentação e os exemplos facilitam o aprendizado e a adoção em uso real

Explicação por tipo de ator

  • Processo (process)

    • Atua como o bloco de construção mais básico dentro do OTP
    • Serve de base para outros tipos de ator, mas não costuma ser usado diretamente com frequência em aplicações Gleam

  • Ator (actor)

    • É o tipo de processo mais usado e oferece funcionalidades semelhantes ao gen_server do Erlang
    • Processa automaticamente mensagens de sistema do OTP e habilita recursos de depuração e rastreamento

  • Supervisor (supervisor)

    • É responsável por iniciar outros processos e por sua supervisão e recuperação
    • Reinicia automaticamente processos filhos em caso de falhas ou exceções
    • Forma a estrutura de tolerância a falhas da aplicação por meio de uma árvore de supervisão (supervision tree)
    • É possível conferir os detalhes de implementação na documentação de gleam/otp/static_supervisor e gleam/otp/factory_supervisor

Limitações e questões

  • Atualmente, os atores não oferecem suporte a todas as mensagens de sistema do OTP, e mensagens não suportadas são ignoradas
  • Alguns recursos da API de depuração do OTP são limitados
  • Se necessário, é possível solicitar suporte a mensagens ainda não implementadas por meio do registro de issues

Conclusão e importância do projeto

  • Gleam OTP amplia os pontos fortes do ecossistema Erlang para a linguagem Gleam, o que é especialmente relevante por permitir segurança de tipos e tolerância a falhas multicore
  • É adequado para aplicações em produção nas quais estabilidade e desempenho são importantes
  • É um projeto open source de alto valor para aprendizado e aplicação prática por startups, desenvolvedores especializados em TI e desenvolvedores em geral

Leituras relacionadas

1 comentários

 
GN⁺ 2025-10-21
Comentários no Hacker News
  • Comecei um projetinho com gleam/lustre e, até agora, estou realmente muito satisfeito
    Se você se interessa por tipagem estática, ausência de null, programação funcional e linguagens da família ML, recomendo experimentar gleam
    E, claro, roda na BEAM
    • Penso a mesma coisa
      Instalei gleam e ele puxou umas 50 dependências no meu sistema, então imagino que sejam pacotes relacionados a Erlang/Elixir
      Fiquei me perguntando como seria se eu quisesse transpilar só para JS. Talvez seja só uma questão de empacotamento no meu sistema
      Seria ainda melhor se houvesse suporte a Lua como alvo de transpilação. Na minha opinião, embutir uma DSL em outro programa com Lua é umas 3 vezes mais fácil do que com um runtime de JS
      De longe, a melhor parte até agora tem sido a comunidade. A qualidade das bibliotecas e dos materiais da comunidade de gleam é extremamente alta
      Me lembra a comunidade Rust, em que as pessoas inteligentes já enfrentaram os problemas difíceis e publicaram soluções muito boas (lustre, squirrel etc.)
      Outra característica é a quantidade de experimentação e tentativas criativas. Coisas que quase não aparecem em ecossistemas de linguagens maiores aqui acabam se destacando. E, à medida que a comunidade cresce, o clima é muito acolhedor
    • Tenho interesse em tudo isso que você mencionou. Só que ainda não entendo direito BEAM nem OTP
      Pode recomendar por onde começar a aprender?
    • Sem experiência com nada do que foi mencionado, fico curioso sobre o que valeria mais a pena aprender primeiro: gleam/lustre ou elixir/phoenix
  • Queria saber se quem usa Gleam também usa algum framework web como Phoenix
    Estou pesquisando porque seria muito bom poder usar Gleam junto com um framework como Phoenix
    No momento estou preparando um projeto novo em Python, mas, se houver alguma opção viável com Gleam, gostaria de tentar
    • Há uma apresentação em vídeo do desenvolvedor de Lustre mostrando uma implementação de algo parecido com LiveView em Gleam/Lustre
      A vantagem é que fica muito fácil escolher quais partes entram no frontend e no backend
      link do YouTube
    • Ainda não existe um framework completo como Phoenix, Django ou Rails
      Em vez disso, há ferramentas usadas com frequência para criar aplicações web
      Lustre é a ferramenta básica de view, e Wisp faz o papel de servidor
      Para SQL, há squirrel e POG (novo, mas popular)
  • PureScript é uma linguagem funcional madura com suporte a backend Erlang
    É uma boa opção se você quer uma alternativa com tipagem estática na BEAM
    É como um dialeto de Haskell, com avaliação estrita e suporte a row polymorphism
    • O backend JS de PureScript é maduro, mas o backend Erlang e seu ecossistema são muito menores que os de Gleam
    • No site oficial e no repositório no GitHub, só vejo que PureScript compila para JS. Queria saber onde você ouviu sobre esse backend Erlang
  • Tenho muito interesse em Erlang/BEAM, mas nunca tive tempo de realmente experimentar
    Fico curioso sobre como isso é usado na prática. As pessoas constroem toda a lógica do serviço nisso ou usam só em partes específicas?
    • Lidero uma equipe e estamos fazendo uma migração gradual para Gleam
      Levamos o padrão "functional core, imperative shell" ao extremo e isolamos o Gleam para lidar com tarefas de computação pesada dentro de uma base de código Ruby on Rails já existente
      Quase não usamos recursos de OTP, e deixamos o Rails focado apenas naquilo em que ele é naturalmente forte, como web UI e HTTP API
      O Rails fica responsável por preparar os valores de entrada dos jobs, e os dados dos jobs são passados ao Gleam via Redis como um único conjunto atômico de valores
      Fizemos um wrapper fino em Elixir para lidar apenas com rede e file I/O, enquanto a lógica de negócio fica nos módulos em Gleam
      Pretendo escrever em breve um artigo explicando com mais detalhes técnicos essa abordagem. É um tema que costuma despertar interesse no HN
    • Na TV Labs, usamos Elixir para serviços web, engine de matching em tempo real, sandboxing de código Lua, comunicação com microcontroladores por protocolo binário, machine learning e várias outras coisas
      Elixir é uma excelente linguagem de propósito geral e tem pontos fortes em várias áreas
      Para uma conversa mais detalhada, veja meu vídeo no Developer Voices
      link do YouTube
    • Recomendo passar no elixirforum.com para conversar
      Muita gente está construindo sistemas sérios usando apenas Erlang/Elixir & BEAM, então, se você tiver dúvidas, o pessoal deve responder bem
    • Já vi os dois estilos
      Depois que você entende OTP o suficiente, construir todo o sistema em cima dele parece natural
      Eu mesmo trabalhei assim por 7 anos, mas percebi que leva bastante tempo para desenvolvedores iniciantes se acostumarem com esse ecossistema
  • Na minha opinião, se o Gleam quiser ser levado mais a sério, seria melhor não colocar mensagens políticas fortes na página do projeto
    Não vejo necessidade de trazer política para a página de um projeto técnico
    Não é uma questão de concordar ou discordar; só acho mais adequado deixar esse tipo de discussão de fora em um contexto profissional
    Caso contrário, a conversa acaba se desviando desnecessariamente do assunto
    • Você está falando daquela única linha no fim da página:
      "Black lives matter. Trans rights are human rights. No nazi bullsh*t."?
      Se alguém decide não usar por causa dessa frase, então está funcionando exatamente como foi planejado
    • Você disse que "a conversa acaba se desviando desnecessariamente do assunto"
      Mas, na verdade, me parece que foi você quem fez isso acontecer
  • Pelo que vejo, o modelo de atores acaba esbarrando em problemas de computação distribuída quando é preciso compartilhar informações entre processos
    Para mim, se o objetivo é tolerância a falhas e uso de múltiplos núcleos, parece melhor usar memória transacional de software e sistemas de efeitos funcionais, como em Scala/ZIO
    Ainda assim, o modelo de atores pode ser usado quando necessário
    Além disso, considerando a maturidade do ecossistema JVM, observabilidade e prontidão para produção, ele me parece superior à BEAM
    • Acho essa visão bem incomum
      Entendo criticar os pontos fracos da BEAM, mas acho estranho criticar justamente aquilo em que ela é forte
      A BEAM funciona com mensagens imutáveis trocadas entre green threads leves e baratas
      Há um sistema robusto de supervisão (supervisor trees), então você não precisa se preocupar com data races nem com travamento de threads
      Tudo isso já vem embutido por padrão, sem boilerplate
      Graças à imutabilidade, o desempenho também é surpreendentemente bom
      No fim das contas, a BEAM é a plataforma mais otimizada para sistemas tolerantes a falhas, distribuídos e concorrentes
    • Houve um ponto que não foi mencionado: Erlang (a base do gleam) é uma linguagem que alcançou 99.9999999% de uptime
      Um dos grandes fatores por trás dessa robustez é sua infraestrutura de supervisão robusta e entre máquinas
      Foi uma linguagem que inspirou fortemente o surgimento dos sistemas de atores
      Literalmente, Erlang existe para fazer isso e faz muito bem
    • Você falou que "o modelo de atores tem dificuldade com compartilhamento entre processos", mas, na prática, o modelo de atores funciona copiando dados ou transferindo propriedade por passagem de mensagens
      Se houver dados que realmente precisem ser compartilhados, então eles necessariamente devem ser imutáveis
    • Você poderia dar um exemplo de situação em que não seja possível passar dados mutáveis como estruturas imutáveis?
      A única coisa em que consigo pensar é computação numérica extremamente pesada, mas, nesse caso, você não escreveria isso diretamente em elixir ou erlang; implementaria como NIF
    • Em Elixir/Gleam/OTP, os programas são inteiramente um conjunto de processos independentes
      Mesmo sem usar explicitamente o padrão actor, repasse de estado e coordenação já são problemas resolvidos
      Há várias primitivas básicas, como tasks, agents, GenServer e Supervisor