blaze: builds de Rust 92x más rápidos que cargo

blaze: rebuilds de Rust en milisegundos

Editar una función en bun —1,25 millones de líneas de Rust— y volver a compilar cuesta 9,11 segundos con cargo build. Con blaze, el mismo ciclo baja a 451 milisegundos: 20 veces menos. Es el dato que mejor resume la propuesta de indexable-inc, cuyo repositorio se describe a sí mismo como builds incrementales de Rust "hasta 92x más rápidos que cargo/rustc".

Para un equipo que compila decenas de veces por día, esa diferencia no es una curiosidad de ingeniería: es tiempo de desarrollador que se recupera o se pierde. Y el tiempo de un senior es la línea más pesada del presupuesto de casi cualquier startup técnica.

La promesa central de blaze es la comodidad: los mismos comandos de cargo, con blaze delante.

• blaze run equivale a cargo run
• blaze test equivale a cargo test
• blaze build equivale a cargo build
• Todo el resto de los comandos de cargo pasa directo a cargo, sin cambios

La instalación es un script de curl. Funciona en macOS sobre Apple silicon y en Linux, con o sin Rust instalado: blaze descarga una sola vez el compilador con el que construye (entre 100 y 135 MB) o usa el de rustup. También hay vías alternativas por crates.io y Nix.

¿Cuánto más rápido es realmente? Los números del repositorio

El titular es el "hasta 92x", pero las cifras más útiles para decidir son los promedios: 10x más rápido en macOS arm64, 24x en Linux aarch64 y 11x en Linux x86-64 frente a cargo build, medidos sobre proyectos reales.

El detalle proyecto por proyecto en Linux x86-64, editando una función y volviendo a compilar, es donde se ve el patrón: cuanto más grande el código, mayor la ganancia.

• ripgrep: de 508 ms a 56 ms (9,1x más rápido)
• nushell: de 1,25 s a 236 ms (5,3x)
• helix: de 2,15 s a 116 ms (19x)
• bun: de 9,11 s a 451 ms (20x)

A eso se suma el modo de edición en vivo: unos 20 ms entre guardar el archivo y tener el programa corriendo con el código nuevo. En proyectos chicos la diferencia es agradable; en un monorepo con un binario de millones de líneas, cambia el ritmo de trabajo de todo el equipo.

¿Cómo funciona la compilación incremental de blaze?

blaze corre al lado de cargo y mantiene el proyecto compilado en memoria. Cuando editas, no rearma el binario desde cero: compila solo las funciones que cambiaron y las escribe dentro del programa que cargo ya había construido, en lugar de reenlazarlo completo. Un programa que se prepara para ello puede recibir el código nuevo mientras sigue en ejecución.

La herramienta se apoya en piezas conocidas del ecosistema: rust-analyzer (de donde toma el análisis y el MIR que compila), Cranelift de Bytecode Alliance (el generador de código rápido), LLVM e inkwell (los niveles optimizados), salsa (el motor incremental de fondo), object y rustd de DioxusLabs, además de los propios crates del compilador de Rust.

El repositorio acumula más de 2.100 commits, 722 estrellas y 22 forks, y el proyecto se distribuye bajo licencia MIT o Apache-2.0. Nació dentro de ix para la app nativa de den, y hasta el 24 de octubre de 2026 se llamaba ra-jit — el comando cargo ra-jit todavía funciona.

Los límites que conviene conocer antes de instalarlo

Ninguna herramienta de este tipo es gratis en todos los frentes. Estos son los puntos que el propio equipo declara:

• Plataformas: solo macOS sobre Apple silicon y Linux. En Windows todos los builds son de cargo.
• Toolchain propia: blaze compila con su propio Rust, blaze-2026-10-25 (el nightly de esa fecha), sin importar la versión que fije el proyecto. Compila tanto código stable como código con #![feature(...)], pero la toolchain del equipo y el CI siguen siendo la palabra final.
• Intercambio de memoria por velocidad: unos pocos GB incluso en un proyecto chico.
• Madurez: el repositorio es explícito en que la herramienta es joven y recomienda mantener cargo check o el CI como árbitro final, y reportar cualquier diferencia contra cargo.

Vale la pena contrastar con el enfoque clásico. Según InfoWorld, los tiempos de compilación de Rust crecen con el tamaño del programa y el número de dependencias, y las palancas tradicionales son otras: usar cargo check para verificar sin compilar del todo, cachear artefactos con sccache (que rinde mucho más en equipos con sistema de archivos compartido), partir el proyecto en subcrates con Cargo workspaces, activar paralelismo, medir con cargo build --timings y probar linkers alternativos como lld o mold.

La diferencia de fondo es la estrategia: esas técnicas reducen cuánto compilas; blaze reduce cuánto recompilas después de cada edición.

¿Qué significa esto para tu startup?

Si tu equipo escribe Rust, el tiempo de compilación es un impuesto silencioso que se paga todos los días. La buena noticia es que ahora hay dos caminos complementarios para bajarlo, y ninguno exige reescribir la arquitectura.

Mide antes de adoptar. Corre cargo build --timings en tu proyecto más pesado y mira dónde se va el tiempo. Si el cuello de botella está en las dependencias y no en tu propio código, blaze no lo va a resolver por sí solo: ahí la jugada es sccache, workspaces o cambiar el linker.

Pilotea en el proyecto más grande, no en el más nuevo. Las ganancias de blaze escalan con el tamaño del binario — de 5x en nushell a 20x en bun. Probarlo en un repo de 5.000 líneas no te va a decir nada útil sobre el retorno real.

Mantén el CI como fuente de verdad. La recomendación del propio repositorio es no reemplazar la verificación final: blaze acelera el ciclo local, el CI decide si el código está bien. Antes de sumarlo al flujo de todo el equipo, verifica que los artefactos coincidan con los de tu toolchain fijada.

Haz la cuenta del costo de oportunidad. Multiplica los segundos que hoy se pierden por build por la cantidad de builds diarios por la cantidad de ingenieros. Si tu equipo espera minutos varias veces al día, la conversación sobre adoptar una herramienta joven deja de ser técnica y pasa a ser financiera.

Y si tu equipo espera por los builds de Rust en CI o necesita builds remotos, el equipo de blaze está trabajando con un grupo reducido de compañías en acceso temprano sobre esas funciones: el repositorio publica un contacto directo para equipos interesados.

Conclusión

blaze ataca uno de los dolores más citados del ecosistema Rust: el ciclo editar-compilar-esperar. Con ganancias de 10x a 24x en promedios reales, hasta 92x en el mejor caso publicado y un modo de edición en vivo de unos 20 ms, la propuesta es difícil de ignorar para cualquier equipo con un binario grande.

Al mismo tiempo, es una herramienta joven, solo para macOS y Linux, que cambia memoria por velocidad y compila con su propia toolchain. El camino sensato no es adoptarla a ciegas ni descartarla por inmadura, sino medir tu cuello de botella, pilotear en el proyecto más grande y dejar que el CI siga teniendo la última palabra.

Fuentes

• blaze — indexable-inc (GitHub) (fuente original)
• Rust slow to compile? Here's how to speed it up (InfoWorld)