Rust – Compilación más rápida con el front-end paralelo en nightly

Artículo original ↗ Discusión en Hacker News ↗

El compilador de Rust está ganando un nuevo modo de front-end paralelo en las compilaciones nightly, con el objetivo de acelerar la compilación de crates grandes que antes no podían aprovechar eficazmente las CPU multinúcleo. Los programadores informan tiempos de compilación reales muy variables: desde compilaciones casi instantáneas en portátiles rápidos hasta compilaciones limpias de 20–30 minutos en monorepos grandes, lo que pone de relieve cómo el número de dependencias, la generación de código, los linkers y el hardware influyen en el rendimiento, y por qué aún importan más mejoras (p. ej., dependencias binarias, backends alternativos, linkers más rápidos). Junto con los detalles técnicos, muchos comentarios reflejan la popularidad inusual de Rust: los usuarios elogian sus herramientas, garantías de seguridad y “experiencia de desarrollador”, mientras que otros cuestionan la intensidad del hype y lo comparan con oleadas anteriores de lenguajes como Ruby, Go y Java.

Paralelismo actual y nuevo en rustc

  • El paralelismo existente es en su mayoría a nivel de crate (por proceso de rustc), no por archivo/módulo en el front-end; el back-end de LLVM ya paraleliza mediante unidades de codegen.
  • Por ello, los crates monolíticos grandes infrautilizan máquinas con muchos núcleos; dividir en más crates tiene costes.
  • El nuevo front-end paralelo en nightly introduce paralelismo dentro del crate y se coordina con Cargo mediante jobserver, así que no se espera que “robe” paralelismo a las compilaciones a nivel de crate.
  • La función es experimental: usa -Z threads, puede bloquearse o colgarse; por defecto usa 1 hilo.

Tiempos de compilación observados y factores que influyen

  • Las experiencias varían mucho: algunos informan compilaciones casi instantáneas en portátiles rápidos para proyectos pequeños/medianos; otros ven muchos minutos en grandes monorepos (decenas a cientos de kLoC y cientos de dependencias).
  • Las dependencias, los proc-macros, la generación de código (p. ej., protobuf) y las dependencias nativas (p. ej., zstd, librdkafka, OpenSSL) se citan como grandes impulsores del tiempo.
  • La elección del linker importa: mold puede acelerar mucho el enlazado frente a los linkers por defecto.
  • Los sistemas de archivos de red pueden ralentizar drásticamente las compilaciones en comparación con discos locales.
  • Algunos monorepos informan compilaciones CI totalmente optimizadas de 10–30 minutos consumiendo mucha RAM (p. ej., 50GB con LTO).

Herramientas, ideas de optimización y límites

  • rust-analyzer a menudo usa más CPU/RAM que rustc, pero muchos consideran que merece la pena.
  • Sugerencias para futuras aceleraciones: dependencias precompiladas/binarias (especialmente scripts de build y proc-macros), backend Cranelift para compilaciones de desarrollo rápidas, mejores linkers, macros y scripts de build aislados en wasm.
  • Algunos sostienen que los grandes beneficios restantes son limitados; el compilador ya está muy optimizado y gran parte del tiempo se va en LLVM/codegen, no en el borrow checking.
  • Otros creen que todavía son realistas mejoras globales de 2–3× (por ejemplo, con artefactos binarios y backends alternativos), pero Rust probablemente nunca igualará la velocidad de compilación de Go debido a la complejidad del lenguaje y la monomorfización.

CI, caché y configuración

  • Las compilaciones basadas en Docker y los runners efímeros de CI complican la caché y pueden inflar los tiempos; las estrategias varían desde un uso agresivo de la caché hasta limpiezas periódicas.
  • Hoy se usan RUSTFLAGS="-Z threads=N" o la detección del entorno (nproc); se espera que el comportamiento estable futuro se alinee con el número de núcleos y el jobserver.

Popularidad de Rust y “marketing”

  • Varios comentarios debaten por qué Rust genera tanto entusiasmo: demanda contenida de programación de sistemas segura, herramientas sólidas (Cargo/crates.io) y buena experiencia de desarrollador frente a C/C++.
  • Algunos ven el entusiasmo como genuino y de base; otros lo perciben como un ciclo repetido de hype similar a oleadas pasadas (Ruby, Java, Go).