Impressões após usar Gleam para o Advent of Code

• Ao resolver os 12 dias de puzzles do Advent of Code 2025 com Gleam, o que mais impressionou foram as mensagens de erro no nível do Rust e o estilo funcional centrado em pipelines
• Funções embutidas como echo, fold_until e list.transpose simplificaram o debugging e a resolução de problemas de combinação, enquanto a segurança baseada em tipos opcionais se mostrou útil no tratamento de puzzles em grade
• A ausência de IO de arquivos e recursos de regex na biblioteca padrão, as restrições de pattern matching em listas e a sintaxe explícita para comparações foram apontadas como incômodos no uso repetido
• Por causa das diferenças no tratamento de inteiros entre a Erlang VM e o alvo JavaScript, foi necessário usar bigi, e em alguns puzzles o problema foi resolvido com chamadas a ferramentas externas (glpsol)
• No geral, a mudança para uma forma de pensar funcional tornou a resolução dos puzzles mais clara, e o autor expressa expectativa de aplicar Gleam em projetos reais, como no desenvolvimento de servidores web

---

Advent of Code 2025 e a escolha do Gleam

• O autor, que completa o Advent of Code todos os anos, escolheu este ano a linguagem Gleam para resolver os puzzles ao longo de 12 dias
  • Neste ano, o evento foi reduzido de 25 para 12 dias, e embora cada problema tivesse alta dificuldade, a estrutura foi adequada para aprendizado
• Como o ritmo dos puzzles era rápido e surgiram problemas complexos antes de o conjunto de ferramentas ficar pronto, isso acabou criando um ambiente ideal para aprender uma nova linguagem

Vantagens da linguagem Gleam

• Destaques para a sintaxe concisa, as mensagens de erro úteis do compilador e o feedback amigável no nível do Rust
• O estilo funcional centrado no operador de pipe combina bem com a estrutura dos problemas do AoC (parsing → transformação → fold)
• A extensão de Gleam para IntelliJ e o LSP funcionaram de forma estável, tornando o ambiente de desenvolvimento confortável
• A programação funcional (FP) leva a uma mudança de pensamento: em vez de código imperativo, passa-se a descrever a essência do problema

Principais recursos e exemplos de uso no código

• echo: uma função simples de saída que permite inspecionar valores no meio do pipeline, facilitando o debugging sem formatação de strings
  • Foi mencionado como ponto incômodo o fato de não haver interpolação de strings, o que faz aumentar o uso do operador <> na criação de textos
• Tipo opcional (dict.get): permite explorar vizinhos em puzzles de grade com segurança, sem precisar de checagens explícitas de limite
• Utilitários de lista
  • list.transpose: simplifica a estrutura do puzzle com a operação de transposição de matriz
  • list.combination_pairs: gera pares de pontos 3D em uma linha, sem loops aninhados
  • fold_until: função de fold com encerramento antecipado ao cumprir uma condição, eficiente em cálculos iterativos dos puzzles

Restrições e incômodos do Gleam

• Ausência de IO de arquivos na biblioteca padrão, contornada com o pacote simplifile
• Recursos de regex também exigem dependência externa (gleam_regexp)
• Restrições no pattern matching de listas: não é possível usar a forma [first, ..middle, last]
• Tratamento explícito de comparações: é preciso usar o tipo order, o que deixa a sintaxe mais verbosa em comparações simples

Uso avançado e exemplos por puzzle

• bigi: usado para evitar overflow de inteiros no alvo JavaScript
• Bitmask com XOR: no Day 10-1, o problema de alternar luzes foi modelado com operação XOR para uma solução eficiente
• Chamada de glpsol: no Day 10-2, foi gerado um arquivo LP e executado um comando externo para resolver equações lineares
• Chave de memoização: no Day 11-2, nó e estado foram usados juntos como chave, permitindo cálculo imediato
• O último puzzle dependia de hipóteses sobre a entrada e foi resolvido com uma simples comparação de área (heuristic_area <= max_area)

Conclusão e planos futuros

• O Gleam mostrou força em segurança e expressividade, apesar dos limites da biblioteca padrão
• Pipelines, tipos option/result, funções de lista e fold_until tornaram a resolução dos puzzles mais clara
• O autor pretende aplicar a linguagem futuramente em projetos reais, como desenvolvimento de servidores web, e afirma que pretende continuar usando Gleam no Advent of Code do próximo ano
• O código-fonte completo está disponível em um repositório no GitHub (tymscar/Advent-Of-Code/2025/gleam/aoc/src)

[GN⁺]

Comentários no Hacker News

• Gleam é realmente uma linguagem linda. Fico pensando como seria bom se o Elixir evoluísse nessa direção em termos de sistema de tipos
  O Gleam também roda sobre a BEAM, a VM do Erlang, e por isso concorrência e processamento de filas ficam muito fáceis
  O ecossistema também é excelente. Ainda assim, preocupa a sensação de que o desenvolvimento de linguagens desde 2021 parou depois da era dos LLMs
  Mesmo assim, o Gleam entrou bem no momento certo antes dessa porta se fechar, e espero que os LLMs logo acompanhem

  • Fico curioso sobre por que você acha que os LLMs fazem a evolução das linguagens parar. Os modelos mais recentes incluem conhecimento até este ano, e também aprendem linguagens novas razoavelmente bem com apenas alguns exemplos
    Como as linguagens não podem ser totalmente diferentes em sintaxe ou filosofia, não acho que isso vá ser um grande problema
  • Não é preciso dizer que Gleam foi construído sobre o OTP. A VM do Erlang é a BEAM, e OTP é o conjunto de bibliotecas e princípios de design do Erlang
    O Gleam oferece por conta própria um subconjunto type-safe de OTP. Veja a biblioteca relacionada: gleam-lang/otp
  • Isso mesmo, a VM do Erlang é a BEAM, não o OTP. A implementação de OTP no Gleam não é tão madura quanto a de Elixir ou Erlang
  • Eu também fiz recentemente meu primeiro projeto em Elixir com recursos de LLM, e tive a impressão de que essa tendência pode, na verdade, acelerar a adoção da linguagem
  • Elixir também está introduzindo gradualmente set-theoretic typing. Documentação relacionada: gradual-set-theoretic-types

• Resolvi o Advent of Code deste ano em Gleam e fiquei bastante impressionado
  Entre os pontos fortes, o desempenho é bom e o language server é surpreendentemente poderoso. Formatação automática, auto import, complementos para pattern matching — a experiência de desenvolvimento é excelente
  Os pontos fracos são que o formatter estica demais o código na vertical e, por priorizar simplicidade, há muita repetição de escrita como list.map. Além disso, o ecossistema de bibliotecas ainda é limitado

  • Eu também me surpreendi com o desempenho. Não chega a ser C, mas é bem mais rápido do que eu esperava. O language server também funciona bem em quase todas as IDEs
    list.map pode ser reduzido com algo como import gleam/list.{range, map}. Também seria interessante portar bibliotecas em C
  • Dá para conviver com esses pontos fracos, mas a ausência de if/else e guard incomoda. O tratamento de ramificações booleanas fica verboso demais
  • Fiz AoC em F# e tive uma sensação parecida. A repetição de namespace como List.map prejudica a descoberta de recursos (discoverability)
  • A formatação de argumentos provavelmente vem do algoritmo do Prettier. Ainda assim, acho muito melhor do que o binpacking do clang-format

• Gosto de Gleam, mas acho uma pena a limitação nas chamadas de funções recursivas. Não dá para chamar funções internas livremente
  Em termos de sintaxe, é menos elegante que Scheme, e conceitualmente é mais simples que Erlang. Ainda assim, a tipagem estática é uma vantagem
  Também usei OCaml, mas a reprodutibilidade do ambiente era pior por problemas com lock file no opam. Fico pensando que seria bom se o ecossistema de SML fosse maior

  • Penso parecido. Haskell é elegante na teoria, mas até um simples hello world tem alto consumo de recursos
    Idris 2 tem tipos dependentes e um design elegante, mas o ecossistema é pequeno, e PureScript é mais prático que Haskell, porém preso ao runtime de JS
  • Se você gosta da família ML, recomendo ReScript v12. Ele fica num ponto bem equilibrado entre OCaml e Gleam

• Ao ver o recurso echo, pensei que seria ótimo se depuradores tivessem por padrão esse tipo de visualização de resultados intermediários
  Seria bom poder ver os resultados no meio de slices de array ou cadeias de filtro sem precisar alterar o código
  Também acho ineficiente usar array bidimensional como grid. Array unidimensional + informação de limites parece mais seguro e eficiente

• Não conheço bem Gleam, mas em list.map(fn(line) { line |> calculate_instruction })
  não daria para simplesmente escrever list.map(calculate_instruction)?

  • Sim, daria. Eu também às vezes faço algo mais complexo, apago depois e acabo deixando essa forma
  • Sim, isso mesmo

• Gleam é uma ótima linguagem. Não me conquistou tanto assim, mas fico feliz de ver as pessoas se divertindo com ela
  Acho que a combinação Gleam + Lustre pode acabar se tornando o novo Elm

  • Como desenvolvedor backend, eu achava Elm atraente, mas me afastei por causa do conflito com o criador e da interrupção dos lançamentos. Ainda assim, aquela arquitetura foi útil em outros projetos
  • Também fiz recentemente um app pequeno com Gleam + Lustre, e funcionou muito melhor do que Elm + PostgREST. Agora pretendo usar em projetos maiores também
  • Dei uma olhada no Lustre, mas o ecossistema ainda é pequeno. Também não havia exemplos ligados a autenticação, então fui de LiveView. Mesmo assim, a ergonomia é boa, e espero que cresça

• Hoje em dia, na era dos LLMs, fico pensando se ainda vale a pena aprender novas linguagens
  Se for uma linguagem que o LLM não aprendeu, preocupa a perda de utilidade como ferramenta

  • No longo prazo, se um LLM não conseguir aprender novas linguagens, então ele fracassou no objetivo de ser uma inteligência geral
  • Havia essa preocupação 1 ou 2 anos atrás, mas hoje o Claude Code escreve Elixir muito bem. Mesmo com poucos dados de treino, isso não parece ser problema
  • Claude também lida bem com Gleam. A documentação e a qualidade das mensagens de diagnóstico são boas, então é fácil para LLMs aprenderem. Oferece diagnósticos no nível de Rust
    Já Swift tem uma sintaxe complexa, o que torna mais difícil para LLMs lidarem com ela
  • Se você vê linguagem como ferramenta, a falta de demanda de mercado pode ser uma limitação ainda maior
  • Espero que novas linguagens não parem por causa das limitações dos LLMs

• Quando vi Gleam no passado, pareceu que faltava despacho dinâmico (interface ou type class); queria saber como isso está hoje

  • Normalmente isso é resolvido no estilo “passe uma struct de funções”. Por ser uma abordagem explícita, isso até ajuda a evitar a complexidade dos genéricos
  • Gleam suporta funções de primeira classe, então despacho dinâmico é possível. No fim, type class ou interface podem ser resolvidos com funções de ordem superior

• [first, ..rest] ou [first, second] funcionam, mas [first, ..middle, last] não.
  Imagino que isso tenha sido bloqueado de propósito por ter custo alto

• Felizmente, a polícia dos títulos de blog apareceu rapidamente
  Link relacionado