Elm 0.19.2, melhorias na velocidade de build

• O Elm 0.19.2 é o primeiro passo de uma sequência de pequenos lançamentos para incorporar melhorias no compilador antes da chegada do Elm 1.0
• Em uma grande base de código Elm, a compilação do zero foi medida em 5,7 segundos, e os builds incrementais ficaram em menos de 350 ms, reduzindo a chance de interromper o fluxo de concentração durante o desenvolvimento
• Desta vez, as melhorias se concentraram em reduzir alocações durante o parsing, e em um experimento com 850 mil linhas foram observados 20% menos cópia pelo GC, 10% menos uso máximo de memória e 7% de ganho geral de velocidade
• Em testes com projetos reais, o nível de melhora variou, e um caso de compilação do zero de 351 módulos caiu de 4,981 segundos para 2,595 segundos, ficando 1,9 vez mais rápido
• Ideias de desempenho e de linguagem vindas do trabalho no Acadia serão incorporadas daqui para frente em lançamentos sem quebra de compatibilidade, antes dos ajustes finais rumo ao Elm 1.0

---

Compilação mais rápida no Elm 0.19.2

• O Elm 0.19.2 é o primeiro lançamento a trazer para o Elm, em pequenas etapas, melhorias acumuladas no compilador
• Um compilador rápido reduz situações em que o desenvolvedor perde o foco ao mudar para outra aba do navegador
  • Se a compilação incremental fica em menos de 400 ms, quase não sobra tempo para mudar de tarefa
• Com base em 850 mil linhas de código Elm, o desempenho foi o seguinte
  • Compilação do zero: 5,7 segundos
  • Build incremental: menos de 350 ms
• As mudanças reais se concentraram em reduzir alocações durante o parsing
  • 20% menos cópia pelo GC
  • 10% menos uso máximo de memória
  • 7% de melhora na velocidade geral
• Em programas com mais de 500 mil linhas, dá para esperar melhorias graduais, e em programas menores o compilador do Elm continua sendo muito rápido
• Em testes em ambiente real, o ganho variou de projeto para projeto
  • Alguns projetos tiveram melhora modesta
  • Em um caso de compilação do zero de 351 módulos, o tempo caiu de 4,981 segundos para 2,595 segundos, uma melhora de 1,9x
• A nova versão pode ser baixada em Elm compiler 0.19.2 release

Próximos lançamentos rumo ao Elm 1.0

• Ideias obtidas no trabalho de compilador relacionado a banco de dados chamado Acadia também devem ser aproveitadas no Elm
  • O Acadia está atualmente em alfa fechado
  • O compartilhamento público está previsto para o fim deste ano
• As ideias a serem refletidas no Elm incluem tanto melhorias de desempenho quanto recursos de linguagem
  • Ex.: parser mais rápido
  • Ex.: tipos equatable e hashable
• Para integrar essas mudanças ao Elm de forma natural, elas serão aplicadas em uma série de pequenos lançamentos sem quebra de compatibilidade
• Depois dos ajustes finais, o plano é avançar para o Elm 1.0
• Quem está conhecendo Elm agora pode começar pelos exemplos online e pelo guia
• Como o Elm 0.19.2 é um patch release, projetos existentes podem baixar a nova versão e usá-la imediatamente

[GN⁺]

Opiniões no Hacker News

• Hoje em dia vejo Elm mais como uma linguagem de pesquisa influente
  Tem um foco claro, não há roadmap público nem suporte oficial, e a liderança parece ter pouco interesse em construir uma comunidade ou uma equipe core
  Ainda assim, a experiência de trabalhar com ela é realmente boa, e isso resultou em vários forks e projetos derivados. Na conferência recente da Gleam, Louis Pilfold brincou que “usuários de Elm mantêm cada um seu próprio compilador”; na prática, há pelo menos 6, e mais 2 foram anunciados no mês passado
  É bom ver Evan se movendo rumo à 1.0, e espero que, depois de chamar Elm de “concluída”, um dos projetos sucessores possa assumir o trabalho difícil de unificar os forks e fazer a comunidade crescer
  Pessoalmente, se eu for procurar algo parecido com Elm da próxima vez, penso em olhar Gleam + Lustre. A combinação de mantenedores que se importam com comunidade e design parece boa, e funciona tanto no frontend quanto no backend

  • A trajetória de Elm foi bem estranha, mas acho que chamá-la de linguagem de pesquisa faz sentido
    Em certo momento ela era divulgada com entusiasmo, havia muitos posts de blog e palestras, e bastante empolgação e adoção
    Aí o autor praticamente desapareceu e o projeto parou
    Claro que é o projeto dele, então ele tem esse direito, mas acho que as expectativas deveriam ter sido definidas melhor desde o início. A divulgação ativa ajudou a espalhar as ideias, mas também fez desenvolvedores sentirem que foram abandonados de repente
  • O melhor de Elm é que ela tem muito aquela sensação de Haskell. Alguns anos atrás, criei coisas divertidas em Elm
    A segunda melhor coisa é a filosofia de “se compila, funciona”. Sinceramente, dá para obter uma sensação parecida na maior parte de Rust. Tem menos sensação de Haskell, mas ainda traz algo como a sombra acolhedora de seus ancestrais funcionais
  • Gren parecia uma sucessora bastante competente, e a comunidade também é ativa e prestativa
  • Eu sou um desses. Estendi a linguagem para incluir vários recursos de conveniência e, essencialmente, fazê-la oferecer suporte a um canal de erro adequado e injeção de dependências por meio de tipos soma que podem ser apagados
    Elm é uma boa linguagem, mas Evan não parece interessado em criar algo realmente útil, e a condução geral da linguagem é uma bagunça
  • Acho que as pessoas ficam decepcionadas com a estagnação justamente porque Elm é tão boa. Mas essa estagnação também é o motivo de Elm ser boa

• Em 2023, escrevi sobre por que eu ainda usava Elm
  https://taylor.town/elm-2023
  Agora, em 2026, continuo usando Elm pelos mesmos motivos :)
  De bônus, Claude parece combinar muito bem com Elm
  https://taylor.town/diggit-000

• Cerca de 2 anos atrás, fiz um experimento de vibe coding com ChatGPT para criar um jogo Snake para navegador em Elm, uma linguagem de que gosto
  Na época, era bem tosco, e concluí que modelos de linguagem grandes poderiam matar Elm
  Hoje estou usando Elm em produção, e os modelos de linguagem grandes ficaram muito melhores. Na verdade, acho que Elm é uma linguagem ideal para modelos de linguagem grandes agora e poderia até aumentar sua adoção. Ela é mais simples que a maioria das linguagens, estável e traz dentro da linguagem uma arquitetura bastante opinativa, o que faz com que as codebases fiquem muito parecidas entre si

  • Graças à IA, também me aprofundei mais em música, comprei um teclado MIDI e configurei um software de DAW de verdade
    Também passei a criar mais coisas em Rust e a ler mais a documentação de Rust. Modelos de linguagem grandes não devem virar desculpa para não aprender aquilo com que você está trabalhando; se for assim, você é um mau engenheiro
    Modelos de linguagem grandes te dão tempo para pesquisar e aprender, de modo que você consiga manter o resultado recebido. Quando você entende o problema, também consegue escrever prompts melhores
  • Dizer que modelos de linguagem grandes podem aumentar a adoção de Elm é, ao mesmo tempo, certo e errado
    No fim, depende de quanto Elm há nos dados de treinamento e no RLHF. Concordo que frameworks ou linguagens estruturadas tornam as codebases mais parecidas e, portanto, mais fáceis de gerar
    Mas só isso não basta; normalmente, a adoção por desenvolvedores é uma discussão muito mais complexa por si só
  • Talvez tenha melhorado, mas fiquei bem decepcionado ao ver agentes como Claude Code tropeçando repetidamente nos espaços em branco significativos de Elm
    Ele lida muito bem com Python, então achei estranho, e Elm está entre as linguagens modernas mais estáveis. Tão estável que as pessoas reclamam que ela não muda. Mas a última vez que tentei foi por volta de 1 ano atrás, então imagino que esteja melhor agora
  • Esse ponto de vista é válido. Eu nunca tinha pensado assim, mas, se o ecossistema não estiver avançando, eu ainda ficaria hesitante

• As limitações relacionadas a JavaScript foram resolvidas? Pelo que me lembro, para interoperar com JavaScript era preciso usar o mecanismo de Ports de Elm, e acho que não deixavam escrever wrappers diretamente
  Parece que também houve uma polêmica quando alguém fez um fork para permitir escrever wrappers JavaScript ou FFI diretamente

  • FFI ainda é tratada majoritariamente por ports. No lado da view, às vezes também se usam Web Components
    Essa é uma escolha intencional, e é bem provável que continue assim até a 1.0 e também depois dela

• Eu nem sabia que este projeto ainda estava vivo. Não estou sendo sarcástico, mas achei que já tivesse acabado

  • O projeto estava morto. O lançamento anterior tinha sido há 7 anos, e, depois que o criador parou a manutenção, a comunidade não conseguiu superar o modelo BDFL e ficou parada
    Então ele estava morto, e agora meio que acabou de ressuscitar. Pelo que sei, nesse meio-tempo a comunidade murchou bastante
  • Não estive profundamente envolvido na comunidade, mas conheço pessoas que participavam na época e, pelo que entendi, a remoção de operadores infixos customizados fez a comunidade perder muito apoio
    Era um recurso muito popular, mas foi removido porque o criador da linguagem não gostava dele, apesar de a comunidade ter pedido com força para mantê-lo
    Tecnicamente talvez tenha sido a decisão certa, mas socialmente foi muito impopular e provavelmente errada, na minha opinião
  • Fico feliz em ver que voltou. Elm sempre teve uma elegância incrível que dá vontade de torcer por ele
  • Nos últimos 2 anos, usei Elm profissionalmente em uma empresa muito lucrativa e enxuta
    Eu não conhecia antes de entrar, mas, por ter experiência com React, Redux etc., aprendi rápido
    A comunidade Elm chamaria isso de recurso. Quanto código React escrito há 6 a 8 anos ainda roda exatamente igual e bem na toolchain React de hoje?
    Os valores são completamente diferentes. Um bom código React de 2026 se parece com código Elm que compila desde 2016
  • Eu também achava que a comunidade em torno do Elm tinha praticamente desaparecido. Ainda assim, parece que o mantenedor solo e criador ainda está por aí
    Nunca usei Elm além dos tutoriais, mas recentemente criei um app full-stack em Gleam e usei principalmente agentes de programação. No começo, controlei a estrutura do código de forma bem rígida, e esse processo funcionou muito bem

• Estou mais curioso sobre o pós-Elm 0.19 do que sobre Elm 1.0. A 0.19 foi a versão que bloqueou todos os módulos nativos não aprovados oficialmente pelo autor do Elm e, para mim, isso marcou efetivamente o fim do Elm

• É difícil imaginar um anúncio pior para o caminho rumo à 1.0. Quem se importa? Sem localização ou suporte a acessibilidade, não faz sentido chamar um framework de UI de pronto para produção na versão 1.0
  Acho que limitar o quanto contribuidores terceiros podiam conectar APIs do navegador matou o impulso do Elm, exceto para projetos de brinquedo
  Hoje parece mais um sandbox para o Evan brincar com ideias de compilador do que algo para produção

  • Acho que isso não é correto. O app Elm que mantenho é totalmente localizado, e considero a acessibilidade bem decente
    A localização é feita com um grande record por idioma, passado para cada parte do app que usa strings. Para plurais ou casos especiais por idioma, dá para colocar funções simples dentro do record, o que é muito conveniente
    A acessibilidade é alcançada combinando bom HTML, ports e, em casos complexos como autocomplete typeahead, web components
  • É só deixar que construam. Quem realmente entende vai reconhecer quando estiver pronto, e quem é levado por moda não tem salvação mesmo
  • Por um lado, fico feliz em ver que o Evan está bem. Ele tem ideias muito boas sobre desenvolvimento de linguagens, e Elm inspirou muitos projetos muito interessantes
    Por outro lado, passar 7 anos sem nada, lançar uma pequena melhoria de desempenho do compilador e chamar isso de “caminho para a 1.0” é meio estranho. Sem má intenção, mas por quê? Já morreu, o luto já acabou, e todo mundo foi embora há muito tempo
    Até sair um lançamento realmente incrível, acho que muita gente não vai se importar

• Parece que o Evan está apontando para algo, mas todo mundo está olhando só para o dedo. Acho que, na verdade, isso não é sobre o Elm em si, mas sobre a preparação para Acadia
  Na palestra dele, Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8, ele mostrou um pouco do que vem trabalhando nos últimos 7 anos. É uma linguagem de consulta que aplica ideias funcionais
  Ele aponta as fronteiras em que a informação de tipos costuma se quebrar em apps web: entre a linguagem e o armazenamento, e entre o armazenamento e o transporte
  O que ganharíamos se pudéssemos preservar informações de tipo através dessas fronteiras? Uma das respostas que ele dá é migrações mais fáceis. Em vez de escrever SQL à mão, você poderia lidar com isso por diferenças de tipos
  Então acho que a pergunta certa é se dá para olhar as mudanças que entram no Elm e inferir como será o Acadia. O que a compilação incremental oferece a uma linguagem de consulta?

  • Considerando a história do Elm, por que deveríamos acreditar que Arcadia não vai acabar igual?
    Por melhores que sejam as ideias, se Arcadia não tiver um modelo de desenvolvimento mais voltado para a comunidade e mais preparado para o futuro, ninguém vai adotá-lo. Na melhor das hipóteses, será apenas “o projeto que inspirou XYZ”
    Evan pode achar que isso é a próxima grande coisa, e pode até estar certo, mas não sei se o mundo pós-Elm vai estar disposto a ouvir

• Eles voltaram atrás naquela decisão de permitir que só a equipe do Elm usasse certos recursos da linguagem? Aquilo pareceu uma decisão capaz de matar a linguagem

• É correto dizer que o Elm perdeu muito impulso? Quase não é mais discutido no HN, e fico me perguntando se isso é um dos motivos para os grandes intervalos entre lançamentos e notícias
  Olhando os intervalos entre lançamentos, o 0.19.2 “Faster builds, and the Road to Elm 1.0” é de julho de 2026, e o 0.19.1 “Friendly syntax hints, faster builds” é de outubro de 2019

[GN⁺]

Opiniões no Lobste.rs

• Uau! Elm 0.19.1 saiu em 21 de outubro de 2019, então já faz 7 anos, e essa também tinha sido a última notícia pública sobre o desenvolvimento do Elm
  É bem legal ver novidades no projeto

  • Estou muito animado com o fato de Evan estar planejando o lançamento v1
  • Eu também vim dizer isso
    Usei Elm em um projeto paralelo e foi muito divertido, mas, visto de fora, a comunidade parecia meio quieta. É uma notícia muito empolgante

• Elm tornou o desenvolvimento web divertido
  Estou ansioso para ver o que a 1.0 vai trazer

• Uma surpresa realmente muito boa
  Sempre gostei da estabilidade do Elm, e parece que a 1.0 também não vai fazer mudanças radicais, o que pessoalmente acho uma boa direção

  • A mudança incompatível descrita parece poder ter um impacto bem grande
    Se == e afins deixarem de aceitar qualquer tipo, vai haver bastante código Elm para alterar. Fico curioso para saber como será o processo de upgrade

• É bom ver uma atualização do Elm
  É um pouco incomum uma linguagem de programação ficar alguns anos sem nenhuma atualização. Entendo o motivo, mas a percepção do público é uma coisa curiosa

  • Sim, especialmente no front-end, onde tudo se move em uma velocidade insana

• Gostei desta notícia
  De vez em quando volto a dar uma olhada no Elm, como uma pausa agradável da loucura do desenvolvimento front-end moderno

• Tive a chance de ver a palestra do Evan na ZuriHac 2026, e fiquei realmente surpreso quando ele deu a entender que um novo lançamento do Elm estava chegando
  Espero que o vídeo seja publicado em breve, mas parece que ele entendeu que uma abordagem voltada à estabilidade não combina bem com a obsessão deste setor por avanços rápidos. Pelo que entendi, o Elm pode passar a dar passos menores e mais rápidos. Estou animado, e aquela palestra me fez sentir muita falta do Elm

• Fico curioso para saber como o Elm vai lidar com recursos mais visíveis, como tipos equatable e hashable
  Uma das escolhas de design controversas da linguagem é evitar recursos mais poderosos de sistema de tipos no estilo Haskell, como typeclasses. Pessoalmente, sempre achei inconveniente que nem mesmo tipos customizados com uma ordenação natural e bem definida possam ser usados como chaves de dicionário. Ainda assim, no geral é uma boa notícia que o trabalho no Elm esteja continuando

  • Acho melhor não esperar muito por recursos no estilo typeclasses
    Pela formulação do post do blog, imagino que seja algo como adicionar mais algumas variáveis de tipo restritas além das que já existem, ou seja, number, appendable, comparable e compappend