2026 é um ano empolgante para o compilador Rust (e para mim)

Artigo original ↗ Discussão no Hacker News ↗

O roteiro em evolução do compilador Rust para 2026 está gerando tanto entusiasmo quanto preocupação, já que recursos planejados como um novo solucionador de traits, avanço em specialization, polymorphization e padrões melhores para debug info prometem reduzir dívida técnica, inchaço de binários e o tamanho do diretório target. Muitos desenvolvedores elogiam a segurança e o desempenho do Rust, mas destacam dores reais com tempos longos de compilação, artefatos de build enormes e exigências de hardware, especialmente em comparação com Go ou Python em projetos grandes e CI. Outros questionam se o Rust pode permanecer a linguagem do futuro ou se um novo ecossistema que combine a segurança do Rust com a simplicidade e velocidade do Go ou do Zig acabará substituindo-o, especialmente à medida que ferramentas assistidas por IA mudam a forma como o código é escrito.

Tratamento do título e peculiaridades do HN

  • Várias submissões tiveram seus títulos alterados automaticamente; as “correções” automáticas do HN às vezes deturpam títulos legítimos ou piadas.
  • As limitações de edição significaram que o título correto só pôde ser corrigido depois.

Tempos de compilação e inchaço do diretório de destino

  • Vários comentários relatam diretórios target/ muito grandes (de dezenas a ~190 GB) e restrições em laptops / discos menores.
  • O pesado debug info do Rust e a monomorfização, além de grandes árvores de dependências e duplicação de crates guiada por features, são citados como os principais motivos do inchaço.
  • Mitigações sugeridas: debuginfo = "line-tables-only" (em breve padrão para dev), o futuro cargo gc e ferramentas para unificar features de dependências entre workspaces.
  • As experiências com tempos de compilação divergem bastante:
    • Alguns veem builds de release de apps reais levando de 15 a 90 minutos, tornando CI e edições dolorosas.
    • Outros relatam builds incrementais de menos de um segundo a poucos segundos mesmo em bases de código grandes, e consideram builds de vários minutos sinal de má arquitetura do projeto ou problemas de ambiente (por exemplo, antivírus nos diretórios de build, árvores de dependências enormes, macros/generics pesados).

Rust vs outros ecossistemas

  • Comparações com Python e Go enfatizam o tempo de “build” quase zero nessas linguagens versus o do Rust.
  • Alguns relatam enormes ganhos de desempenho em runtime ao reescrever Python em Rust, justificando compilações mais lentas.
  • Outros argumentam que tempos longos de compilação são um risco operacional (por exemplo, incidentes atrasados por rebuilds) e tornam Go/Zig atraentes apesar dos trade-offs.
  • A discussão observa que generics/monomorfização e macros derive inerentemente custam tempo de compilação, ao contrário do modelo de despacho mais dinâmico do Go.

Evolução da linguagem e alternativas

  • Alguns acham que o futuro do Rust é brilhante e que ele já é “o presente” (kernel Linux, Windows, navegador).
  • Céticos preveem uma futura linguagem que combine a simplicidade do Go, a velocidade de compilação do Zig e a segurança do Rust, possivelmente com sintaxe parecida com a de Lisp.
  • Outros apontam para OCaml e sistemas de programação com GC como alternativas viáveis em alguns domínios.

Roteiro do compilador e ferramentas

  • Entusiasmo em torno do novo solucionador de traits, Polonius e do progresso em direção a recursos há muito parados, como specialization e melhorias ligadas a async (Return Type Notation, funções async em traits).
  • Polymorphization é discutido como uma forma de reduzir duplicação de código; formas básicas podem ser habilitadas por padrão, com formas mais agressivas para builds de debug/otimizados para tamanho.
  • O cache persistente do rust-analyzer depende de trabalho no Salsa; há suporte, mas é preliminar e ainda não é prioridade.
  • Pequenas perguntas sobre o papel do Clippy em um futuro pesado em LLMs; o consenso é que ele continuará útil.