Cruller: el runtime Zig de Bun, continuado en Zig 0.16
Un nuevo proyecto llamado Cruller recupera el runtime de JavaScript basado en Zig que Bun abandonó, con la intención de convertir una parte recortada en un motor integrable y orientado a producción para el ecosistema Zig, en lugar de ser un reemplazo completo de Bun. Los comentaristas debaten si este enfoque tiene sentido frente a usar simplemente Node o JavaScriptCore directamente, y cuestionan los riesgos de tener runtimes distintos para desarrollo y producción. El fork también provoca argumentos más amplios sobre la calidad del código en el Zig original de Bun, la ética de recortar el historial de git y la viabilidad a largo plazo de los forks comunitarios tras el cambio de Bun a una reescritura en Rust bajo Anthropic.
Alcance y objetivos del proyecto
- Cruller se describe como la extracción y actualización del antiguo runtime de Bun basado en Zig a Zig 0.16, centrándose en un runtime mínimo de JS para despliegue.
- Omite deliberadamente funciones de Bun como la gestión de paquetes, el empaquetado, la transformación de TypeScript y el test runner.
- Objetivo: servir como un runtime de JavaScript ligero e integrable para el ecosistema Zig, en lugar de ser un reemplazo completo de Bun.
Relación con Bun, Node, JavaScriptCore, Rust, Zig
- Cruller no se presenta como competidor de Bun actual (ahora en Rust), sino como un complemento para ejecutar en producción código desarrollado con Bun.
- Reutiliza una parte del código de Bun de la era Zig en lugar de seguir la reescritura en Rust de Bun.
- Algunos cuestionan por qué no usar simplemente Node o integrar directamente JavaScriptCore, argumentando que el «intermediario» añade riesgo de mantenimiento.
- Sus defensores ven valor en un envoltorio Zig y señalan compilar a un único binario como una gran ventaja de despliegue.
Viabilidad del fork y política del ecosistema
- Hay opiniones divididas sobre hacer un fork: algunos predicen que desaparecerá rápidamente; otros citan forks históricos exitosos (compiladores, bases de datos, proyectos multimedia, herramientas de hosting).
- Se debate si esto es «realmente» un fork; varios insisten en que reutilizar ampliamente código existente lo convierte en uno, independientemente del mensaje.
- Algunos comentaristas vinculan el cambio de lenguaje de Bun a tensiones en torno a la postura de Zig sobre contribuciones generadas por LLM, pero los motivos concretos se disputan y no están evidenciados en el hilo.
Historial de Git y licencias
- Fuerte crítica al commit aplastado y huérfano del fork, que descarta el historial de git y la autoría upstream.
- Las preocupaciones incluyen:
- Depuración más difícil (pérdida del contexto de
git blame/bisect). - Menor trazabilidad de licencias/derechos de autor.
- Depuración más difícil (pérdida del contexto de
- Una minoría dice que rara vez usa el historial; muchos otros argumentan que es esencial en bases de código grandes o antiguas.
Divergencia entre desarrollo y runtime de producción
- El modelo de Cruller —desarrollar con el Bun completo, desplegar con un runtime recortado— genera preocupación.
- Varios comentaristas evitarían usar runtimes distintos para desarrollo y producción debido al riesgo de diferencias sutiles que solo aparezcan en producción.
Participación de LLM
- Un participante afirma que el README del proyecto, los comentarios y algunos commits parecen generados por LLM; esto se menciona, pero no se fundamenta ni se resuelve en el hilo.