Como acelerar o compilador Rust em setembro de 2026

Melhorias gerais e áreas de foco

• Comentadores destacam a recente redução média de ~4,5% no tempo de execução em centenas de benchmarks como algo impressionante.
• Muitos observam que os grandes ganhos vêm de mudanças algorítmicas (por exemplo, melhor travessia do fluxo de controle reduzindo massivamente certas chamadas de análise), e não de micro-otimizar loops críticos.
• O novo trabalho em Polonius/solução de traits e em “fazer análise cara apenas quando necessário” é visto como algo que empurra Rust para uma compilação mais direcionada e orientada por demanda.

Por que rustc é lento (e como ele se compara)

• Não há uma única causa: os fatores citados incluem generics e monomorfização, idioms pesados em iteradores, resolução complexa de traits e inferência de tipos, borrow checking, otimizações pesadas do LLVM e grandes quantidades de informações de debug.
• Vários posts enfatizam que o Rust idiomático usa naturalmente muitos generics (por exemplo, Option, Result, cadeias de iteradores), o que gera muito IR para o LLVM e mais trabalho para o linker.
• Alguns argumentam que a solução de traits normalmente não é o principal gargalo; o volume bruto de IR, além do LLVM e do linking, dominam.
• Em comparação com C, Rust e C++ são vistos como amplamente semelhantes em velocidade e ambos muito mais lentos que C; Go e Zig são mencionados como linguagens que trocam deliberadamente recursos e otimizações por compilação rápida.
• Outros argumentam que Rust poderia ter sido projetado mais perto da fronteira de Pareto, tanto em segurança/desempenho quanto em tempo de compilação, mas que a velocidade de compilação foi secundária durante o design da linguagem.

Ferramentas, backends e linking

• O linking é frequentemente um gargalo em projetos com muitos símbolos, mesmo em builds de debug; linkers mais novos (por exemplo, wild) melhoram a situação, mas exigem configuração explícita.
• Cranelift é elogiado por gerar código muito rapidamente, mas criticado por suporte fraco ao debugger e por intrínsecos ausentes; alguns duvidam que ele se torne um backend estável.
• Expansão de macros e proc-macros é identificada como um custo importante. O cache experimental de proc-macros (-Zcache-proc-macros) mostra ganhos de dois dígitos em crates pesados em macros, mas a estabilização e a semântica de ativação opcional continuam em aberto.

Estrutura do projeto, cache e uso de disco

• Dividir grandes bases de código em múltiplos crates melhora o paralelismo e reduz a recompilação por edição, mas não resolve o tempo de linking.
• Caches globais e compartilhados (por exemplo, sccache, ferramentas mais novas como kache) são fortemente recomendados; sem eles, muitos sandboxes paralelos recompilam as mesmas dependências.
• Grandes projetos Rust podem acumular diretórios target e artefatos incrementais enormes (centenas de GB), forçando limpezas manuais periódicas; como recuperar espaço de cache com segurança é descrito como um problema não resolvido ou muito difícil.
• Alguns sugerem wrappers ou locks globais de build para evitar sobreposição de CPU, o que, caso contrário, pode tornar os builds substancialmente mais lentos.

Ideias de compilação paralela e especulativa

• Há trabalho ativo em um frontend paralelo e em TPDE (type-driven partial compilation) que poderia trazer ganhos maiores.
• Um comentarista descreve um branch experimental que emite metadados mais cedo para que crates dependentes possam começar antes, gerando reduções substanciais no wall-time em projetos profundamente encadeados; lidar com relatórios de erro e trabalho “desperdiçado” especulativo segue sendo um desafio em aberto.

Rust, agentes e velocidade de iteração

• Vários posts enquadram Rust como uma ótima opção para saídas de “IA agêntica”: nativo, com baixa taxa de defeitos, legível para humanos e bom para apps desktop sérios.
• Outros relatam ter abandonado Rust em favor de Go ou outras linguagens porque compilações lentas, dependências pesadas e grande uso de disco tornam fluxos de trabalho com múltiplos agentes dolorosos.
• Alguns argumentam que, para grandes organizações e projetos realistas, equipes Rust e Go são aproximadamente igualmente produtivas, então focar apenas no tempo de compilação é enganoso; outros contra-argumentam que compilações mais rápidas ainda poderiam melhorar bastante a produtividade, especialmente para iteração guiada por IA.

Trade-offs de design da linguagem e alternativas

• Go e Zig são citados como exemplos em que o desempenho do compilador moldou o design da linguagem; Rust é descrito como querendo “comer o bolo e tê-lo também”, com muitos recursos e verificações.
• Alguns apontam para outros ecossistemas (D, OCaml, Haskell, Ada, Delphi, C++) onde existem compiladores rápidos, intérpretes, REPLs ou ferramentas de hot reload, e argumentam que a principal lacuna do Rust é ecossistema/ferramentas, não um custo inerente da linguagem.
• A orphan rule é chamada de um grande ponto de dor, mas também um ganho de coerência em tempo de compilação; há interesse em relaxá-la em workspaces, embora isso possa complicar a compilação e o desempenho.
• Alguns veem Nim ou outras linguagens “meio-termo” como opções mais equilibradas entre a complexidade do Rust e a simplicidade do Go/Zig.

Financiamento, políticas de LLM e influência

• Doações corporativas à infraestrutura do Rust são geralmente bem-vindas por permitirem trabalho sustentado em performance; alguns sugerem que conseguir mostrar uma redução de 5% no tempo de espera dos desenvolvedores justifica esse investimento.
• Outros temem que grandes doadores possam influenciar sutilmente as prioridades, mesmo sem controle formal, financiando primeiro o trabalho que atende às suas necessidades.
• A política de LLM do projeto Rust proíbe enviar código gerado por LLM diretamente, mas permite usar LLMs para análise e assistência; pelo menos um engenheiro do compilador observa explicitamente usar LLMs dessa forma.
• Há debate sobre se código escrito por LLM ou grandes concessões gratuitas de tokens de empresas de IA deveriam ter um papel maior em acelerar o desenvolvimento do compilador.

Ceticismo sobre o valor do Rust na era da IA

• Alguns participantes questionam por que Rust é atraente em um mundo pesado em IA: argumentam que a performance bruta em runtime importa menos do que antes, enquanto a verbosidade do Rust, os tipos complexos e os tempos de compilação lentos desperdiçam recursos humanos e de IA.
• Tipagem estática (e, por analogia, as garantias de segurança do Rust) é retratada por esses céticos como “rodinhas de treino” de que os LLMs não precisam, semelhante ao uso excessivo percebido de TypeScript, levando a bases de código superengenheiradas e cheias de cerimônia.
• Outros discordam fortemente, enfatizando que as garantias do Rust e sua eficiência em runtime são exatamente o que é necessário para sistemas robustos e com poucos defeitos, mesmo que isso signifique pagar mais em tempo de compilação.