Rust – Compilação mais rápida com o front-end paralelo no nightly
O compilador do Rust está ganhando um novo modo de front-end paralelo nas compilações nightly, com o objetivo de acelerar a compilação de crates grandes que antes não conseguiam aproveitar eficientemente CPUs multinúcleo. Programadores relatam tempos de compilação no mundo real muito variados — de builds quase instantâneos em laptops rápidos a builds limpos de 20–30 minutos em grandes monorepos — destacando como contagem de dependências, geração de código, linkers e hardware influenciam o desempenho, e por que melhorias futuras (por exemplo, dependências binárias, back-ends alternativos, linkers mais rápidos) ainda importam. Junto dos detalhes técnicos, muitos comentários refletem a popularidade incomum do Rust: usuários elogiam suas ferramentas, garantias de segurança e “developer experience”, enquanto outros questionam a intensidade do hype e o comparam a ondas anteriores de linguagens como Ruby, Go e Java.
Parallelismo atual e novo no rustc
- O parallelismo existente é em grande parte ao nível da crate (por processo
rustc), não por arquivo/módulo no front-end; o back-end LLVM já paraleliza via unidades de codegen. - Crates monolíticas grandes, portanto, utilizam mal máquinas com muitos núcleos; dividir em mais crates tem custos.
- O novo front-end paralelo do nightly introduz paralelismo intra-crate e coordena com o Cargo via jobserver, então não se espera que ele “roube” parallelismo das compilações ao nível de crates.
- A funcionalidade é experimental: usa
-Z threads, pode entrar em deadlock ou travar; o padrão é 1 thread.
Tempos de compilação observados e fatores que influenciam
- As experiências variam muito: alguns relatam builds quase instantâneos em laptops rápidos para projetos pequenos/médios; outros veem muitos minutos em grandes monorepos (dezenas a centenas de kLoC e centenas de dependências).
- Dependências, proc-macros, geração de código (por exemplo, protobuf) e dependências nativas (por exemplo, zstd, librdkafka, OpenSSL) são citados como grandes responsáveis pelo tempo.
- A escolha do linker importa: mold pode acelerar significativamente a ligação em comparação com os linkers padrão.
- Sistemas de arquivos de rede podem deixar os builds dramaticamente mais lentos do que discos locais.
- Alguns monorepos relatam builds CI totalmente otimizados de 10 a 30 minutos consumindo muita RAM (por exemplo, 50 GB com LTO).
Ferramentas, ideias de otimização e limites
- O rust-analyzer muitas vezes usa mais CPU/RAM do que o rustc, mas muitos consideram o custo válido.
- Sugestões para futuras melhorias de velocidade: dependências pré-compiladas/binárias (especialmente scripts de build e proc-macros), back-end Cranelift para builds rápidos de desenvolvimento, linkers melhores, macros e scripts de build em sandbox wasm.
- Alguns argumentam que os grandes ganhos restantes são limitados; o compilador já é fortemente otimizado e muito tempo vai para LLVM/codegen, não para borrow checking.
- Outros acham que ainda são realistas melhorias totais de 2–3× (por exemplo, com artefatos binários e back-ends alternativos), mas o Rust provavelmente nunca igualará a velocidade de compilação do Go devido à complexidade da linguagem e à monomorfização.
CI, cache e configuração
- Builds baseados em Docker e runners efêmeros de CI complicam o cache e podem inflar os tempos; as estratégias variam entre reutilização agressiva de cache e limpezas periódicas de cache.
RUSTFLAGS="-Z threads=N"ou detecção de ambiente (nproc) são usados agora; o comportamento estável futuro deve se alinhar com o número de núcleos e o jobserver.
Popularidade do Rust e “marketing”
- Vários comentários discutem por que o Rust recebe tanto hype: demanda reprimida por programação segura de sistemas, ferramentas fortes (Cargo/crates.io) e boa experiência de desenvolvimento em comparação com C/C++.
- Alguns veem o entusiasmo como genuíno e de base; outros o encaram como um ciclo repetido de hype semelhante a ondas anteriores (Ruby, Java, Go).