Bun ha sido convertido a Rust. ¿Y ahora qué?

Objetivos y resultados percibidos del port a Rust

• Beneficio principal declarado: pasar de Zig a Rust manteniendo el comportamiento, con la mayoría de las pruebas todavía pasando.
• Algunos ven ganancias reales: compilación más simple, localización explícita del código unsafe, potencial para un endurecimiento progresivo.
• Otros creen que la reescritura es en gran medida performativa o una maniobra de marketing, especialmente dado el unsafe que sigue existiendo y la implicación de un LLM.
• Algunos señalan benchmarks neutros a mejores y binarios más pequeños como puntos de datos interesantes de Zig vs. Rust.

Uso de unsafe y seguridad de memoria

• La preocupación central: decenas de miles de bloques unsafe, muchos generados por un LLM, socavan la promesa central de Rust de seguridad de memoria.
• Quienes lo apoyan sostienen que el unsafe marcado explícitamente ya es una mejora frente a Zig/C: obtienes una lista concreta de “cosas por arreglar”.
• Los críticos responden que si incluso un bloque no es correcto, todo el programa puede exhibir comportamiento indefinido; con “gazillions” de bloques escritos por LLM, ese riesgo es alto.
• Comparaciones: se dice que la densidad de unsafe de Bun es aproximadamente el doble que la de Deno, aunque ambos deben envolver motores de JS en C/C++ inseguros.

“Vibe coding” impulsado por LLM y confianza

• Hay un fuerte desacuerdo sobre confiar en un runtime traducido en su mayor parte por un LLM:
  • Algunos: la traducción con un buen conjunto de pruebas es uno de los mejores usos de un LLM.
  • Otros: un runtime es infraestructura fundamental; publicar un millón de líneas de código de IA en gran medida no revisado es “flagrantemente irresponsable”.
• Debate sobre “vibecoding” como etiqueta: algunos creen que borra matices entre herramientas y proceso; otros la usan como abreviatura para un uso poco riguroso de la IA.
• Preocupaciones de que la fuerte dependencia de la IA erosione la capacidad de los desarrolladores para juzgar la calidad del código.

Pruebas, corrección y medición de seguridad

• Hay amplio acuerdo en que las altas tasas de aprobación de pruebas demuestran equivalencia de comportamiento, no seguridad de memoria.
• Algunos señalan que el propio conjunto de pruebas se ajustó durante el port, lo que hace que cifras exactas como “99.8%” sean algo poco claras.
• Se enfatiza que las pruebas no pueden cubrir todos los modos de fallo; siguen siendo esenciales la comprensión profunda y la revisión.

Proceso, Rust idiomático y trabajo futuro

• Muchos dudan de que un PR de un millón de líneas hecho en una semana pudiera haber sido revisado seriamente.
• Preocupa que el resultado sea Rust no idiomático con semánticas de memoria al estilo Zig, lo que dificulta el refactorizado a largo plazo.
• Algunos sostienen que el trabajo real ahora es una rearquitectura extensa y cuidadosa para eliminar unsafe; otros sospechan que un diseño nuevo en Rust habría sido mejor que un port directo.