Blaze promete builds incrementales de Rust hasta 92 veces más rápidos que cargo

Un desarrollador edita una sola función en bun, un proyecto de 1,25 millones de líneas de Rust, y vuelve a compilar. Con cargo build, ese ciclo tarda 9,11 segundos. Con blaze, la herramienta de indexable-inc, tarda 451 milisegundos: unas 20 veces menos. Es la cifra que mejor resume una propuesta que el repositorio presenta con otro número, el de «hasta 92x» más rápido que cargo y rustc en builds incrementales.

Para un equipo que compila decenas de veces por día, la diferencia se traduce en tiempo de desarrollador recuperado o perdido. El texto subraya que el tiempo de un perfil senior suele ser la línea más pesada del presupuesto de una startup técnica. La promesa de blaze es además de uso simple: blaze build, blaze run y blaze test equivalen a sus comandos hermanos de cargo, y el resto de los comandos pasa directo a cargo sin cambios. La instalación es un script de curl, funciona en macOS con Apple silicon y en Linux, con o sin Rust instalado. Descarga una sola vez el compilador con el que construye, de entre 100 y 135 MB, o usa el de rustup. También existen vías por crates.io y Nix.

El titular de 92x es el mejor caso publicado; los promedios sirven más para decidir. Frente a cargo build, medidos sobre proyectos reales, el repositorio reporta 10x en macOS arm64, 24x en Linux aarch64 y 11x en Linux x86-64. El detalle por proyecto en Linux x86-64, editando una función y recompilando, muestra un patrón: a más código, más ganancia. ripgrep pasa de 508 ms a 56 ms (9,1x); nushell, de 1,25 s a 236 ms (5,3x); helix, de 2,15 s a 116 ms (19x); y bun, de 9,11 s a 451 ms (20x). Se suma un modo de edición en vivo, con unos 20 ms entre guardar el archivo y ver el programa corriendo con el código nuevo.

El mecanismo es este: blaze corre junto a cargo y mantiene el proyecto compilado en memoria. Al editar, no rearma el binario desde cero; compila solo las funciones que cambiaron y las escribe dentro del programa que cargo ya había construido, sin reenlazarlo completo. Un programa preparado para ello puede recibir el código nuevo mientras sigue en ejecución. Se apoya en piezas conocidas: rust-analyzer (de donde toma el análisis y el MIR que compila), Cranelift de Bytecode Alliance, LLVM e inkwell para los niveles optimizados, salsa como motor incremental, object y rustd de DioxusLabs, además de crates del propio compilador de Rust.

El proyecto acumula más de 2.100 commits, 722 estrellas y 22 forks, con 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 sigue funcionando.

Los límites los declara el propio equipo. Solo funciona en macOS sobre Apple silicon y Linux; en Windows todos los builds son de cargo. Compila con su propio Rust, blaze-2026-10-25 (el nightly de esa fecha), sin importar la versión que fije el proyecto, y maneja tanto código stable como código con #![feature(...)]. Cambia memoria por velocidad: unos pocos GB incluso en un proyecto chico. Y es joven: el repositorio recomienda mantener cargo check o el CI como árbitro final y reportar cualquier diferencia contra cargo.

El texto contrasta con las palancas clásicas que cita InfoWorld: cargo check, sccache, Cargo workspaces, paralelismo, cargo build --timings y linkers alternativos como lld o mold. La diferencia es de estrategia: esas técnicas reducen cuánto se compila; blaze reduce cuánto se recompila tras cada edición. Para quien lo evalúe, la recomendación es medir primero con --timings, pilotear en el proyecto más grande y no en el más nuevo, mantener el CI como fuente de verdad y calcular el costo de oportunidad de la espera. Para builds remotos o de CI, el equipo trabaja en acceso temprano con un grupo reducido de compañías y publica un contacto directo.