¿La reescritura de Bun 1.4 en Rust no pinta bien?
Crece la preocupación por la reescritura de Bun 1.4 en Rust y su fuerte dependencia de la codificación asistida por IA, ya que los repetidos incumplimientos de fechas de lanzamiento y una cadencia de versión estable estancada han sacudido la confianza de algunos primeros adoptantes. Los partidarios responden que las compilaciones canary ya están en producción en empresas como Anthropic y Prisma, sostienen que las grandes reescrituras suelen ser accidentadas y ven esto como una prometedora prueba de concepto para el desarrollo impulsado por LLM. El debate no solo aborda la estabilidad y la hoja de ruta de Bun frente a alternativas como Node y Deno, sino también si el código generado por IA puede sustentar de forma fiable infraestructura crítica.
Sentimiento general sobre Bun 1.4 y la reescritura en Rust
- Algunos usuarios dicen que Bun ha sido “increíble” en la práctica (rápido, herramientas integradas, mejor DX) y son optimistas de que la reescritura en Rust mejore la seguridad y las fugas.
- Otros informan inestabilidad constante: fallos aleatorios de compilación, fugas de memoria y regresiones que borraron cualquier ahorro de recursos, lo que les hizo lamentar haber adoptado Bun para proyectos “serios”.
- Unos pocos están usando 1.4 canary (la reescritura en Rust) en producción y dicen que básicamente funciona, con problemas menores (p. ej., fallos de renderizado en el REPL).
Cadencia de lanzamientos, “no se está publicando” y comunicación
- Una preocupación central: los lanzamientos antes frecuentes de Bun se estancaron durante ~3 meses durante la reescritura en Rust, tras una cadencia histórica de 2–3 semanas.
- Los críticos sostienen que las repetidas declaraciones públicas optimistas del estilo “se publica mañana”, seguidas de retrasos, minan la confianza y sugieren problemas con la reescritura.
- Los defensores dicen que una gran reescritura naturalmente pausa los lanzamientos; la cautela y el pulido antes de un corte importante es razonable.
- Hay frustración porque las compilaciones canary se usan intensamente en el mundo real (p. ej., por grandes usuarios) pero no apareció una versión estable oficial durante mucho tiempo, bloqueando la adopción en entornos conservadores.
- Hacia el final del hilo, la gente señala que en realidad 1.4 ya se ha lanzado.
Calidad del código, código muerto y métricas
- Una línea de ataque cita grandes volúmenes de PRs abiertos y afirmaciones de código muerto como prueba de que la reescritura “no pinta bien”.
- Otros califican esto de argumento débil o engañoso:
- Se dice que más de 5k PRs abiertos no prueban una caída en la calidad.
- El ejemplo de “11k líneas de código muerto” se corrige: esa eliminación se aplicó a la base de código Zig anterior, no al port en Rust.
- Algunos argumentan que <1% de código muerto en un proyecto de un millón de líneas sería aceptable; otros dicen que el código muerto debería ser cero y que existen linters para ello.
Node, Deno y alternativas
- Algunos preguntan por qué hace falta una alternativa a Node en absoluto; citan la creciente biblioteca estándar de Node, el test runner, el soporte para TS y el soporte para archivos env.
- Los defensores de Bun destacan las herramientas integradas (gestor de paquetes, test runner, bundler, soporte de imágenes y SQL) y el rendimiento como ventajas importantes frente a la dispersión de la toolchain de Node.
- Otros sugieren usar simplemente pnpm/yarn sobre Node, o Deno, por mayor estabilidad y alineación con estándares.
Código generado por IA y debate más amplio sobre IA
- La reescritura se ve como un caso de prueba clave para el desarrollo asistido por LLM:
- Los partidarios dicen que las reescrituras de lenguaje a lenguaje encajan naturalmente con los LLM, especialmente cuando se validan con tests.
- Los escépticos cuestionan el mantenimiento a largo plazo, el posible código “espagueti” y el coste económico total una vez se cuentan la supervisión humana y el gasto en tokens.
- Algunos esperan explícitamente que la reescritura fracase para pinchar la burbuja de que “la IA reemplazará a los desarrolladores”; otros argumentan que la gente está esforzándose de más tanto para probar como para refutar el éxito de los LLM.