Reescribiendo Bun en Rust

Contexto de la reescritura y proceso

• Bun fue portado de Zig a Rust en gran medida mediante el modelo Fable de Anthropic y Claude Code, durante ~11 días, usando ~50+ flujos de trabajo automatizados y amplias suites de pruebas.
• La reescritura se presenta como en su mayor parte mecánica, función por función, preservando la estructura y los modelos de datos, y luego refinada iterativamente mediante revisiones adversariales con IA y supervisión humana.
• La versión en Rust ya lleva funcionando en producción para Claude Code desde mediados de junio sin fallos catastróficos evidentes, lo que algunos ven como una validación sólida.

Coste y economía

• El gasto en tokens fue de ~5.9B de entrada no cacheada, 72B de entrada cacheada, 690M de tokens de salida, con un coste estimado de ~$165k a precios de API.
• Muchos sostienen que esto es más barato y mucho más rápido que un pequeño equipo trabajando durante un año; otros replican que equipos humanos (especialmente fuera de regiones de alto coste) o modelos más débiles/baratos podrían igualarlo con un coste total inferior.
• Algunos señalan que, incluso si ahora es caro, es probable que reescrituras similares se vuelvan mucho más baratas.

Calidad del código, seguridad y mantenibilidad

• Beneficios reportados: se corrigieron fugas de memoria, hubo menos fallos, una reducción de ~20% del tamaño del binario (con optimizaciones del enlazador) y ganancias de rendimiento de ~5%.
• Quienes lo apoyan dicen que las garantías de Rust, los errores del compilador y las herramientas de Miri/memoria ofrecen una seguridad más sólida que Zig más guías de estilo.
• Los críticos destacan un gran uso de unsafe (~13k instancias al principio), UB inicial detectado por Miri, y argumentan que muchos bloques unsafe y comentarios SAFETY débiles sugieren invariantes de Rust mal entendidas.
• Hay desacuerdo sobre si el código generado por IA a esta escala es realmente “mantenible” o solo parece estable bajo pruebas.

Impacto en Zig y los debates sobre lenguajes

• Algunos ven esto como mala imagen para Zig: un port “ingenuo” alejándose de él aparentemente mejoró la estabilidad y el tamaño.
• Otros subrayan que el código Zig de Bun se escribió contra un lenguaje en evolución, pre-1.0, y que mejoras similares habrían sido posibles ajustando el código y las herramientas de Zig.
• Largos subhilos debaten Rust vs Zig vs C/C++ vs lenguajes con GC en torno a seguridad, ergonomía, tiempos de compilación y adecuación como objetivos para LLM.

Herramientas de IA, “vibe coding” y el futuro del trabajo

• Muchos consideran esto una demostración de la traducción a gran escala asistida por LLM cuando está respaldada por una sólida suite de pruebas independiente del lenguaje.
• Algunos llaman al proceso “vibe coding” (LLM‑dirigido sin revisión humana exhaustiva); otros sostienen que la traducción con pruebas es distinta del desarrollo de IA especulativo y sin restricciones.
• Hay ansiedad activa sobre lo que estas capacidades significan para los trabajos de software, especialmente los puestos intermedios; otros esperan efectos tipo Jevons (más software producido, no menos ingenieros).

Gobernanza del proyecto y preocupaciones de la comunidad

• Varios comentaristas critican cómo se comunicó y fusionó la reescritura:
  • Primeras garantías de que la rama Rust podría descartarse frente a una fusión rápida posterior.
  • Sin plan LTS ni de correcciones de seguridad para la línea Zig, obligando de facto a actualizar.
  • La percepción de que Bun está más guiado por el marketing y las necesidades internas de Anthropic que por su comunidad externa.
• Quienes lo apoyan responden que el código pre‑fusión se supone que sea tosco, las regresiones se documentaron y corrigieron, y los resultados para los usuarios parecen positivos hasta ahora.