Erlang/OTP 29.0

• O daemon SSH agora desativa por padrão os serviços shell e exec, de modo que, sem configuração explícita, usuários autenticados não possam executar código Erlang arbitrário
• Ao iniciar o daemon SSH, o subsystem SFTP também não é mais ativado por padrão, reforçando os padrões de segurança
• O atributo -unsafe foi adicionado para permitir marcar funções inseguras, e o compilador passa a gerar avisos por padrão para chamadas de funções sempre conhecidas como inseguras no Erlang/OTP
• O xref agora pode encontrar chamadas de funções inseguras e funções sem documentação, e a filtragem do atributo ignore_xref também passou a ser tratada pelo próprio xref
• Nas configurações padrão de SSL, x25519mlkem768 tornou-se o grupo de troca de chaves mais preferido, e o algoritmo padrão de troca de chaves do SSH também foi alterado para mlkem768x25519-sha256, que combina ML-KEM-768 e X25519
• No caminho de código padrão do sistema Erlang, a posição do diretório de trabalho atual . foi movida da primeira para a última, alterando a ordem de carregamento
• As builds 32-bit do Erlang/OTP para Windows não são mais fornecidas
• Os native records da EEP-79 foram implementados e são considerados um recurso experimental no Erlang/OTP 29
• Foram adicionados o guard BIF is_integer/3, comprehensions multivalor com base na EEP 78 e o binding de variáveis dentro de comprehensions por meio do recurso compr_assign
• O compilador adiciona avisos padrão para catch, exportação de variáveis para fora de subexpressões, and/or e padrões de match alias como {a,B} = {X,Y}, oferecendo opções para desativar cada um deles
• Os antigos guard tests serão removidos da linguagem no Erlang/OTP 30, e o aviso existente sobre uso de guards obsoletos continua valendo
• Com io_ansi, é possível emitir sequências ANSI/Virtual Terminal Sequence no terminal, e com ct_doctest é possível testar exemplos na documentação de módulos Erlang e em arquivos de documentação

[GN⁺]

Comentários do Hacker News

• As melhorias parecem bem boas. Desativar o daemon SSH por padrão e também desativar o SFTP por padrão é uma boa mudança em termos de segurança
  O módulo io_ansi também parece bem interessante. Hoje em dia o Erlang não tem exatamente muita fama de ser ideal para criar aplicações complexas de linha de comando, então isso pode ajudar bastante no futuro se entrar na biblioteca padrão. O jeito como fwrite funciona naturalmente entre nós também é exatamente o tipo de vantagem que se espera do Erlang
  A adição de Native Records também é interessante. Hoje no Elixir parece que, dependendo do caso, se mistura record, tuple e map, então fico curioso para ver como isso vai ser usado daqui para frente. Como o EEP diz, os records existentes não devem ser totalmente descontinuados, mas isso parece uma melhora considerável
  https://www.erlang.org/doc/apps/ssh/ssh.html
  https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
  https://github.com/erlang/eep/pull/81

  • Não acho que o daemon SSH jamais tenha sido ativado ou iniciado automaticamente. A redação dos dois itens é diferente, mas o sentido parece ser que, ao iniciar o daemon SSH, os componentes listados não serão mais iniciados por padrão
    O daemon SSH agora segue o princípio secure by default, com shell e serviço exec desativados por padrão. Se isso não for configurado explicitamente, impede que usuários autenticados executem código Erlang arbitrário
    O subsistema SFTP também não é mais ativado por padrão ao iniciar o daemon SSH

• Para quem tem curiosidade sobre o que significa OTP em Erlang/OTP: originalmente é um conjunto de bibliotecas e princípios para padronizar a criação de aplicações altamente confiáveis e tolerantes a falhas para telecomunicações
  A ideia básica vale uma leitura rápida da introdução de “OTP Design Principles”
  https://www.erlang.org/doc/system/design_principles.html

  • OTP = Open Telecom Platform

• Se o seu app de produção ainda está abaixo da 29, talvez valha a pena atualizar o quanto antes para esta versão ou para o patch mais recente. Acabei de fazer deploy em produção e a varredura automática de segurança detectou 2 CVEs CRÍTICAS com datas entre fevereiro e maio de 2026, além de vários itens de alto risco

  • Tem a lista?

• Fico curioso se ainda há gente usando Erlang em projetos novos
  Sei que tem muita gente aqui que gosta de Elixir, mas estou falando de Erlang puro
  Se você ainda usa Erlang, queria saber por que prefere isso ao Elixir

  • Só neste ano, sim. Tenho trabalho novo de IoT baseado em AtomVM, um servidor de aplicações escrito em Erlang e um framework TUI ainda em desenvolvimento
    Elixir não me traz vantagens práticas em relação ao Erlang. Claro que pode ter seus pontos fortes, mas Erlang combina mais com a forma como eu penso. Também queria tentar aprender ou buscar ajuda de um jeito mais social, como em encontros da comunidade, mas não tenho encontrado bem o lugar certo para mim

• Alguém pode explicar a arquitetura interna?

  • Depende de qual parte da arquitetura interna você quer dizer. The BEAM Book pode ser interessante
    https://blog.stenmans.org/theBeamBook/

• Fico curioso para ver como os records vão se encaixar no ecossistema

  • Eu ia dizer “mas records já existem há décadas?”, então fui ler o changelog
    Interessante. Fico pensando se um dia vai existir um mundo em que o Elixir compile maps para native records

• Alguém sabe se o WhatsApp ainda é baseado em Erlang?

  • Sim
    Eles usam Erlang desde o começo dos anos 2010, e foi nessa época que o setor de tecnologia descobriu que o WhatsApp sustentava mais de 400 milhões de usuários ativos com algo como 30 engenheiros
    Na época, entrei em contato com um engenheiro de lá, e ele gentilmente respondeu algumas perguntas por e-mail quando eu ainda morava nos EUA. No fim, até tomamos um café e mantemos contato até hoje
    Dá para dizer que Erlang ainda é uma parte importante do WhatsApp
  • Pelo que apresentaram na Code BEAM Europe 2025, parece bem provável que ainda seja o caso: https://www.youtube.com/watch?v=tC435RGwRCI
  • Não sei por conhecimento direto, mas saí em 2019 e os repositórios públicos relacionados a Erlang do WhatsApp ainda seguem ativos. Até onde eu sei, Erlang também não se espalhou pela Meta inteira, então, se o WhatsApp tivesse saído de Erlang, não haveria muito motivo para continuarem esse trabalho com Erlang depois disso
  • Sim. Um ex-funcionário meu trabalha lá agora
  • Sim. Eles usam Erlang e também estão aumentando o uso de Rust

• Suporte ao atributo -unsafe adicionado: a oportunidade perfeita para reescrever em Rust /s

• Sinceramente não sei quem usa Erlang. Já usei Rails e depois experimentei Phoenix, e achei muito mais difícil fazer as coisas acontecerem
  Não entendo toda a empolgação com Phoenix
  Para um desenvolvedor solo, Rails provavelmente é o sistema de webapp mais produtivo. LLM também escreve código Ruby on Rails muito bem. Mesmo com o corpus de treinamento enorme de Python, na minha experiência escreve bem melhor do que Django
  Eu escrevo apps experimentais em Rails e, quando estabilizam, reescrevo em Go. Quando o escopo do app ainda não está claro, começar direto em Go consome muito mais tokens, enquanto Rails é muito eficiente para isso
  Hoje em dia nem React nem Angular são mais necessários: no Rails uso Hotwire e em Go uso HTMX
  Até o próprio fórum de Erlang usa Discourse, feito em Rails

  • Escrevo apps em Elixir em tempo integral desde 2016. Os clientes ficam muito satisfeitos com o fato de não verem crashes. Na prática, todas as aplicações que coloquei em produção nos últimos 10 anos tiveram 100% de uptime, excluindo falhas de hardware, sistema operacional e rede que fogem do meu controle
    Talvez valha a pena ampliar um pouco a perspectiva
  • Eu diria que Rails só é mais rápido que Phoenix, em termos de velocidade de desenvolvimento, mais ou menos no primeiro dia. Depois disso você começa a esbarrar em lógica implícita e coisas como method_missing, e passa mais tempo tentando entender como tudo funciona
    Elixir/Phoenix é mais explícito nesse aspecto, então para manutenção de longo prazo — isto é, depois da primeira semana — acaba sendo muito mais confortável. Não existe estado escondido, você não fica tentando descobrir de onde vem ModuleName.method(params), e também não precisa configurar nada só para conseguir executar aquele método; basta passar os argumentos corretos. A desvantagem é basicamente uma biblioteca menor de pacotes prontos para uso
  • Quer adivinhar o que o Ruby Discord usa?
  • O principal interesse de Phoenix costuma ser OTP, os channels e o LiveView. Dito isso, LiveView provavelmente não seria a minha escolha em 2026, e se você não precisa desses recursos o apelo pode ser menor
    Ecto também não é ruim
    Claude Code escreve código Elixir muito bem
    Surpreendentemente, com ou sem LLM, você é mais produtivo usando tecnologias que já conhece
  • Há uma ironia enorme em dizer, de forma tão absoluta, “quando o escopo do app ainda não está claro, começar direto em Go consome muito mais tokens, enquanto Rails é muito eficiente”. Depois de escrever tudo isso, acabou deixando claro que nem é você quem escreve o código afinal