Rewriting Bun in Rust

Puntos clave

1. Idea clave: las reescrituras de lenguaje ya no son una decisión sin retorno. Históricamente, cambiar el lenguaje de un proyecto como Bun (535.496 líneas de Zig) = ~1 año para un equipo pequeño, con una congelación de correcciones de errores, seguridad y funcionalidades — por tanto poco realista, por tanto «nunca se hace». La IA agéntica transforma esta disyuntiva: «¿Y si dedico una semana a probar si el nuevo modelo de Anthropic puede reescribir Bun en Rust?» Resultado: 11 días.
2. El argumento del «por qué Rust» trata de bucles de retroalimentación, no de gustos. La clase de error dominante (use-after-free, double-free, llamadas a free omitidas en las rutas de error) proviene de mezclar memoria GC (JavaScriptCore) × memoria manual (Zig) — un caso para el que pocos lenguajes están diseñados. En Rust seguro, estos se convierten en errores de compilación + limpieza automática (Drop, RAII). «Los errores del compilador son un mejor bucle de retroalimentación que una guía de estilo». Zig favorece el defer explícito (sin flujo de control oculto); la alternativa — smart pointers caseros — ofrecía «una ergonomía peor que la de Rust, sin las garantías».
3. La restricción que hace viable la apuesta: una suite de pruebas independiente del lenguaje. Las pruebas de Bun están escritas en TypeScript → no dependen del lenguaje de implementación. El port busca un cambio mínimo de comportamiento, validado por esta suite (60.624 pruebas, 1,39M de llamadas expect(), 0 pruebas eliminadas u omitidas, verificado a mano). Esta es la red de seguridad que permite fusionar 1M de líneas generadas por un LLM.
4. Port mecánico > rediseño. Elección explícita: preservar la arquitectura de Zig, minimizar los cambios, dejar el Rust idiomático para después del lanzamiento de v1.4. «¿Incremental o todo a la vez?» → todo a la vez (como en su port original de esbuild de Go a Zig, sin LLM). Todo lo demás «es solo táctica».
5. El harness: ~50 flujos de trabajo dinámicos en Claude Code, en bucle durante 11 días. Pseudocódigo tal como se expone: while (task = todo.pop()) { result = task(); feedback = await [review(result), review(result)]; apply(feedback) }. Flujos de trabajo dedicados: generar la guía de porting → portar mecánicamente cada archivo .zig a .rs → corregir errores de compilación por crate → conseguir que pasen los subcomandos (bun test, bun build) → conseguir que pase toda la suite → refactorizaciones/limpieza.
6. La revisión adversarial, el núcleo de la fiabilidad. Un segundo Claude, en un contexto separado, que ve ÚNICAMENTE el diff (nada del razonamiento del implementador), encargado de «encontrar por qué está mal». Proporción de 1 implementador / 2+ revisores adversariales / 1 corrector; el implementador no revisa, el revisor no implementa (como con los humanos, la persona que escribe el código está sesgada a favor de fusionarlo). Detecta errores que son sintácticamente idénticos pero semánticamente distintos: un Box liberado antes de un uv_close asíncrono (UAF + double-free); un timespec negativo vía trunc frente a floor; un unwrap_or eager que provoca un panic donde un unwrap_or_else lazy no lo habría hecho.
7. «Corregir el proceso que genera el código, no el código a mano.». Principio rector: cuando aparece un error o un antipatrón, se edita el flujo de trabajo/prompt, no el archivo. P. ej.: cuando Claude añade comentarios largos para justificar workarounds, se añade una regla para los revisores → «Si necesitas un comentario de un párrafo entero para justificar por qué el workaround está bien, el código está mal — corrige el código.» Una edición de prompt, unas horas, y el comportamiento desaparece.
8. Preparación (reducción de riesgo) antes de escribir una sola línea. ~3 horas de discusión con Claude → PORTING.md (mapeo de patrones/tipos Zig→Rust). Luego un flujo de trabajo que analiza la duración de vida de cada campo de struct (lectura + rastreo de flujo de control, 2 revisores adversariales), serializado en LIFETIMES.tsv para las demás instancias de Claude. Luego una prueba piloto sobre 3 archivos antes de lanzarse sobre los 1.448.
9. El paralelismo y sus falsos inicios. Lanzar los 1.448 archivos de golpe → las instancias de Claude colisionan (git stash/stash pop/reset --hard). Solución: prohibir cualquier operación git que no haga commit de un archivo específico, nada de cargo, ni comandos lentos. Luego 4 shards / 4 worktrees × 16 Claude = ~64 instancias de Claude simultáneamente. Pico: 1.300 líneas/min, 695 commits/h, 58 commits/min. Un grep lento bloqueó el disco por IOPS insuficientes en la instancia EC2.
10. ~16.000 errores de compilación tratados como una cola. Divididos en ~100 crates (compilación más rápida) → revela dependencias cíclicas (el código de Zig era una única unidad de compilación) → flujos de trabajo de clasificación seguidos de flujos de trabajo de refactorización. cargo check escribe los errores en un archivo agrupado por crate → distribuido entre 64 instancias de Claude. Aislamiento reforzado mediante systemd-run (cgroups) para las pruebas de fugas de memoria/estrés (10k procesos, gigabytes de disco saturado, sockets TCP saturados).
11. El camino hacia el verde (Buildkite CI, 6 plataformas). De 972 archivos de prueba fallando a 23 en 2 días; Linux totalmente en verde ~1 día antes que Windows; build #54202 = 6/6 plataformas en verde → fusión. Fusionar ≠ publicar: suficiente confianza para hacer commit, todavía no para lanzar.
12. Coste, cuantificado y asumido. Antes de la fusión: 5,9 mil millones de tokens de entrada sin caché + 690M de salida + 72 mil millones de lecturas de caché ≈ 165.000 $ a precios de API. Alternativa humana realista: 3 ingenieros, ~1 año, durante el cual «no habríamos mejorado la compatibilidad con Node.js, corregido errores/vulnerabilidades, ni lanzado funcionalidades» — por tanto nunca se habría hecho. «La alternativa realista era no hacer nada y seguir corrigiendo los errores para siempre».
13. Tras la fusión, el trabajo continúa. 11 rondas de revisión de Claude Code Security; fuzzing guiado por cobertura 24/7 de todos los parsers (JS/TS/JSX/CSS/JSON5/TOML/YAML/Markdown/INI/Bun Shell/semver/.patch), 100 mil millones de ejecuciones → ~15 PR (el fuzzer envía la reproducción a Claude, que presenta el PR, seguido de revisión humana). ~4% de código unsafe (~13.000 bloques unsafe / ~780.000 líneas), de los cuales 78% en una sola línea (un puntero procedente de C++ o de una llamada C) — se espera que disminuya a medida que se avance hacia Rust idiomático. 19 regresiones conocidas, todas corregidas (p. ej., la macro debug_assert! eliminada en los builds de release → HMR roto).
14. El modelo y la producción. Una versión preliminar de Claude Fable 5 («un modelo de clase Mythos»); los flujos de trabajo dinámicos de Claude Code sostuvieron 64 instancias de Claude durante 11 días («de lo contrario habría tenido que escribir mi propio harness»). Primera versión sobre Bun-en-Rust: Claude Code v2.1.181, +10% de arranque más rápido en Linux, cambios mínimos visibles para el usuario → prueba de madurez para producción.
15. Relacionado. revisión de código basada en agentes / verificación adversarial y consenso («The End of Code Review» de Monperrus, la serie ADLC al estilo Kent Beck «prosecution not code review» / «tests are the spec»); Loop/Harness Engineering (Lushbinary, Osmani, OpenAI Codex agent-first, la técnica Ralph, git worktrees); skills de Claude Code y flujos de trabajo dinámicos; Zig ya presente en el corpus (ZML/LLMD, soberanía del silicio); FinOps de tokens / coste por resultado.