Cómo acelerar el compilador de Rust en septiembre de 2026

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

Optimizar el compilador de Rust sigue siendo una prioridad importante, con trabajos recientes en mejores algoritmos, compilación incremental y paralela, y caché de macros que aportan mejoras medibles de alrededor del 4–5% en grandes suites de benchmarks. Los comentaristas debaten por qué las compilaciones de Rust siguen siendo mucho más lentas que las de C, Go o Zig —señalando genéricos y monomorfización, la pesada optimización de LLVM, las macros y el análisis estático—, mientras comparten estrategias prácticas de mitigación como dividir crates, usar backends y enlazadores alternativos, y cachés del compilador. Muchos ven unos tiempos de compilación más rápidos como algo crítico tanto para la productividad humana como para los flujos de trabajo de agentes de IA, argumentando que el rendimiento y las garantías de seguridad son valiosos, pero deben equilibrarse con la velocidad de iteración.

Mejoras generales y áreas de enfoque

  • Los comentaristas destacan la reciente reducción media del tiempo total de ~4,5% en cientos de benchmarks como algo impresionante.
  • Muchos señalan que las grandes victorias provienen de cambios algorítmicos (por ejemplo, un mejor recorrido del flujo de control que reduce enormemente ciertas llamadas de análisis), no de microoptimizar bucles calientes.
  • El nuevo trabajo en Polonius/solución de traits y en “hacer solo el análisis costoso cuando sea necesario” se ve como un impulso para que Rust avance hacia una compilación más dirigida y basada en la demanda.

Por qué rustc es lento (y cómo se compara)

  • No hay una única causa: entre los factores citados están los genéricos y la monomorfización, los patrones intensivos en iteradores, la resolución compleja de traits y la inferencia de tipos, el borrow checking, las optimizaciones pesadas de LLVM y la gran cantidad de información de depuración.
  • Varios mensajes subrayan que el Rust idiomático usa muchos genéricos de forma inherente (por ejemplo, Option, Result, cadenas de iteradores), lo que genera mucho IR para LLVM y más trabajo para el enlazador.
  • Algunos sostienen que la resolución de traits no suele ser el principal cuello de botella; el gran volumen de IR, junto con LLVM y el enlace, domina.
  • En comparación con C, Rust y C++ se consideran ampliamente similares en velocidad y ambos mucho más lentos que C; de Go y Zig se dice que sacrifican deliberadamente funciones y optimizaciones para compilar rápido.
  • Otros argumentan que Rust podría haberse diseñado más cerca de la frontera de Pareto tanto en seguridad/rendimiento como en tiempo de compilación, pero la velocidad de compilación fue secundaria durante el diseño del lenguaje.

Herramientas, backends y enlace

  • El enlace suele ser un cuello de botella en proyectos con muchos símbolos, incluso en compilaciones de depuración; enlazadores más nuevos (por ejemplo, wild) mejoran las cosas, pero requieren configuración explícita.
  • Cranelift recibe elogios por su generación de código muy rápida, pero también críticas por su pobre soporte para depuración y la falta de intrínsecos; algunos dudan de que llegue a convertirse en un backend estable.
  • La expansión de macros y proc-macros se identifica como un coste importante. La caché experimental de proc-macros (-Zcache-proc-macros) muestra mejoras de dos dígitos en crates con muchas macros, pero la estabilización y la semántica opt-in siguen abiertas.

Estructura del proyecto, caché y uso de disco

  • Dividir grandes bases de código en múltiples crates mejora el paralelismo y reduce la recompilación por edición, pero no soluciona el tiempo de enlace.
  • Se recomiendan encarecidamente las cachés globales y compartidas (por ejemplo, sccache, herramientas más nuevas como kache); sin ellas, muchos entornos aislados paralelos recompilan las mismas dependencias.
  • Los grandes proyectos en Rust pueden acumular enormes directorios target y artefactos incrementales (cientos de GB), obligando a limpiezas manuales periódicas; cómo recuperar espacio de caché de forma segura se describe como un problema no resuelto o muy difícil.
  • Algunos sugieren envoltorios o bloqueos globales de compilación para evitar la sobresuscripción de CPU, que de otro modo puede hacer que las compilaciones sean sustancialmente más lentas.

Ideas de compilación paralela y especulativa

  • Hay trabajo activo en un frontend paralelo y en TPDE (compilación parcial guiada por tipos) que podría aportar mejoras mayores.
  • Un comentarista describe una rama experimental que emite metadatos antes para que las crates dependientes puedan empezar antes, logrando reducciones sustanciales del tiempo total en proyectos profundamente anidados; gestionar los informes de error y el trabajo “desperdiciado” especulativo sigue siendo un reto abierto.

Rust, agentes y velocidad de iteración

  • Varios mensajes presentan Rust como una buena opción para salidas de “IA agéntica”: nativa, con pocos defectos, legible para humanos y adecuada para aplicaciones de escritorio serias.
  • Otros informan haber abandonado Rust por Go u otros lenguajes porque las compilaciones lentas, las dependencias pesadas y el gran uso de disco hacen dolorosos los flujos de trabajo con múltiples agentes.
  • Algunos sostienen que, para grandes organizaciones y proyectos realistas, los equipos de Rust y Go son aproximadamente igual de productivos, así que centrarse solo en el tiempo de compilación es engañoso; otros replican que compilar más rápido aún podría mejorar mucho la productividad, especialmente en la iteración impulsada por IA.

Compromisos de diseño del lenguaje y alternativas

  • Go y Zig se citan como ejemplos en los que el rendimiento del compilador dio forma al diseño del lenguaje; Rust se describe como queriendo “tener el pastel y comérselo también” con muchas funciones y comprobaciones.
  • Algunos señalan otros ecosistemas (D, OCaml, Haskell, Ada, Delphi, C++) donde existen compiladores rápidos, intérpretes, REPLs o herramientas de recarga en caliente, y argumentan que la principal carencia de Rust es el ecosistema/herramientas más que un coste inherente del lenguaje.
  • La orphan rule se llama un gran punto de dolor, pero también una ganancia de coherencia en tiempo de compilación; existe interés en relajarla en workspaces, aunque esto podría complicar la compilación y el rendimiento.
  • Unos pocos ven Nim u otros lenguajes “intermedios” como opciones más equilibradas entre la complejidad de Rust y la simplicidad de Go/Zig.

Financiación, políticas de LLM e influencia

  • Las donaciones corporativas a la infraestructura de Rust suelen recibirse con agrado porque permiten trabajo sostenido en rendimiento; algunos sugieren que poder mostrar una reducción del 5% en el tiempo de espera de los desarrolladores justifica esa inversión.
  • Otros temen que los grandes donantes puedan influir sutilmente en las prioridades incluso sin control formal, financiando primero el trabajo que sirve a sus necesidades.
  • La política de LLM del proyecto Rust prohíbe enviar código generado por LLM directamente, pero permite usar LLM para análisis y सहायता; al menos un ingeniero del compilador menciona explícitamente usar LLM de esta forma.
  • Hay debate sobre si el código escrito por LLM o las grandes concesiones de tokens gratuitos de empresas de IA deberían desempeñar un papel mayor en acelerar el desarrollo del compilador.

Escepticismo sobre el valor de Rust en la era de la IA

  • Algunos participantes cuestionan por qué Rust resulta atractivo en un mundo dominado por la IA: argumentan que el rendimiento bruto en ejecución importa menos que antes, mientras que la verbosidad de Rust, los tipos complejos y los tiempos de compilación lentos desperdician recursos tanto humanos como de IA.
  • La tipificación estática (y por analogía las garantías de seguridad de Rust) se presenta por estos escépticos como “rueditas de entrenamiento” que los LLM no necesitan, de forma similar al uso excesivo percibido de TypeScript que lleva a bases de código sobrediseñadas y cargadas de ceremonias.
  • Otros discrepan firmemente, enfatizando que las garantías de Rust y su eficiencia en tiempo de ejecución son exactamente lo que se necesita para sistemas robustos y con pocos defectos, incluso si eso implica pagar más en tiempo de compilación.