Mis pensamientos sobre la reescritura de Bun en Rust
(andrewkelley.me)- Andrew Kelley, creador de Zig, interpreta la reescritura de Bun en Rust no tanto como una cuestión de victoria o derrota de las funciones del lenguaje, sino como un episodio que reveló el deterioro de la relación entre la Zig Software Foundation (ZSF) y Bun/Oven
- Al principio, Bun reconocía a Zig como base de sus logros de rendimiento y donaba alrededor de US$60,000 al año a la ZSF, pero después de convertirse en una startup respaldada por VC, crecieron las inconformidades en torno a la operación de la organización y la calidad del código
- A la ZSF le preocupaban en la base de código de Bun las implementaciones tipo hack, el abuso de assertions y la poca limpieza de bugs y deuda técnica en comparación con la rápida incorporación de funciones; también le resultaba una carga que Bun pareciera el caso emblemático de Zig
- Kelley critica que el artículo de Bun sobre su migración a Rust plantee la reducción de bugs como un tema de guía de estilo vs. funciones del lenguaje, y considera que el punto central real es el tiempo de ingeniería invertido en eliminar bugs y gestionar la calidad del código
- La ZSF agradece las donaciones de Bun, pero después de la adquisición por parte de Anthropic terminaron tanto las donaciones como la relación; ve como algo positivo que la reescritura en Rust haya separado los intereses comerciales de Zig y Bun
La relación inicial entre Bun y Zig
- Jarred se unió a la comunidad de Zig hace unos 5 años, y Kelley lo veía como alguien con mucha “beginner energy”: una persona que probaba rápido y aprendía mucho
- A medida que Bun empezó a llamar la atención como toolchain de JavaScript, también comenzó a concentrarse más interés en Zig
- Kelley cree que Jarred podría haber generado ingresos estables para los estándares de San Francisco solo con crowdfunding, pero que adoptó una mentalidad al estilo Thiel Fellowship y un enfoque típico de Silicon Valley, eligiendo el capital de riesgo
- En sus inicios, Bun era favorable al proyecto Zig
- En el sitio web de Bun reconocía a Zig por sus logros de rendimiento
- Estableció una donación mensual de alrededor de US$60,000 al año a la Zig Software Foundation
- Kelley evalúa que incluso en el artículo de Bun sobre la reescritura en Rust, el agradecimiento al proyecto Zig parece sincero
Las grietas tras convertirse en una startup respaldada por VC
- Después de que Bun se convirtiera en una startup respaldada por VC, Jarred pasó de ser un desarrollador que hacía crecer el open source junto con la comunidad a estar más cerca de ser un operador de negocio
- El mensaje de reclutamiento de Oven anticipaba una carga de trabajo intensa durante los primeros 9 meses aproximadamente, y aclaraba que si work-life balance significaba “tener mucho tiempo sin trabajar”, quizá no era el lugar adecuado
- Kelley dice que, al hablar con candidatos y empleados de Oven, escuchó repetidamente mensajes negativos sobre el rol de Jarred como gerente
- Los puntos mencionados como problemas fueron falta de comunicación, expectativas poco realistas, poca empatía y falta de experiencia
- Como resultado, miembros de la comunidad que querían trabajar con Zig empezaron a evitar Oven y Bun
- Cuanto más se enfocaba Jarred en la productividad y en la estrategia de exit de la startup, más se alejaba de la visión de largo plazo de Kelley para Zig
- Por ejemplo, Jarred pidió que se priorizara la implementación de Language Server Protocol y la integración con VSCode, pero Kelley tenía planes más amplios
Los problemas de calidad de código de Bun vistos por la ZSF
- El problema central señalado por Kelley es la calidad del código
- El equipo de Zig lee el código fuente de proyectos de usuarios, revisa cómo los cambios del lenguaje afectan a los usuarios y prueba roturas y regresiones de rendimiento causadas por los cambios
- En la base de código de Bun fueron aumentando prácticas de programación que preocupaban a la ZSF
- Se seguían acumulando implementaciones tipo hack
- Había abuso de assertions
- En comparación con la rápida incorporación de funciones, había poco tiempo para reflexión, eliminación de bugs y resolución de deuda técnica
- Kelley temía que esta forma de trabajar de Bun pudiera combinarse con críticas a Zig sobre seguridad de memoria, y quería tomar distancia social del proyecto Zig
- La ZSF intentó orientar a Bun hacia mejores prácticas de programación, pero no logró resultados
La adquisición por Anthropic y la reescritura en Rust
- Dentro de la ZSF surgió la impresión de que Bun se acercaba a ser una responsabilidad neta (net liability)
- Aunque Bun parecía el caso representativo de Zig, en realidad resultaba más cercano a un ejemplo de “así no se debe escribir código Zig”, lo que era una carga
- Kelley veía desde el principio como endeble el plan de negocio de Bun de vender “alguna cosa de cloud”, y pensaba que si algún día se vendía, Zig también podría recibir indirectamente mala publicidad
- Tras la adquisición por parte de Anthropic, la ZSF sintió alivio
- Las donaciones se interrumpieron silenciosamente, y la ZSF ya lo esperaba
- El lado de Bun ni canceló ni asistió a las reuniones mensuales, y la relación se dio por terminada
- La ZSF sospechaba que en cuestión de días llegaría una reescritura en Rust, y la apoyaba
- Después de la adquisición por Anthropic, incluso la conexión indirecta de que Claude usaba Bun y Bun estaba escrito en Zig empezó a ser una carga para la comunidad de Zig
- Aumentaron las drive-by slop contributions
- Llegaron usuarios entusiastas de la IA que pegaban salidas de LLM en publicaciones del foro
- Kelley temía que Zig llegara a ser conocido como un lenguaje de programación asociado con la IA
- Cuando Jarred anunció la reescritura en Rust, Kelley lo recibió con mucho agrado y expresó la sensación de que ahora “no es mi problema”
Réplica al artículo de Bun sobre la reescritura en Rust
- Kelley considera que el artículo de Bun sobre la reescritura en Rust está bien escrito, pero señala varios problemas centrales
-
El punto central de la reducción de bugs
- El artículo de Bun plantea la situación como si, para evitar bugs, hubiera que elegir entre una guía de estilo y las funciones del lenguaje de programación
- Para Kelley, el principal método para eliminar bugs es invertir recursos de ingeniería en encontrarlos y quitarlos
- TigerBeetle dedicó tiempo a encontrar y eliminar bugs y mantuvo una relación saludable con la ZSF, mientras que Bun no hizo ninguna de las dos cosas
-
La contradicción sobre la suite de pruebas
- Kelley interpreta que el artículo de Bun usa como argumento que su suite de pruebas es suficiente para desplegar 1 millón de líneas de código sin revisar
- Kelley se pregunta entonces por qué el código Zig tenía tantos bugs molestos, y si la suite de pruebas no puede detectar bugs en el código Zig pero sí puede detectar bugs en 1 millón de líneas de código sin revisar
-
Rendimiento y LTO
- El artículo de Bun atribuye la mejora de rendimiento a LTO, pero Kelley dice que Zig soportó LTO durante todo el periodo de Bun
- Zig antes habilitaba LTO por defecto, pero lo quitó de los valores predeterminados porque había demasiados bugs de LLVM, y esos bugs también afectan a Rust
- Kelley cree que es muy probable que la ZSF haya recomendado habilitar LTO y que Bun no haya escuchado
-
Fuzzing
- El artículo de Bun insinúa que hicieron fuzzing de forma diligente sobre el código Zig, pero Kelley dice que en una llamada el equipo de Bun afirmó que no hacía fuzzing de nada
-
Tamaño del binario y
comptime- El artículo de Bun presenta varias tareas de ingeniería para reducir el tamaño del binario como si fueran una justificación de la reescritura en Rust, pero Kelley considera que esas tareas no tienen relación con la reescritura en sí
- Esas tareas se parecen más a trabajos de ingeniería que debieron haberse hecho desde el principio en la base de código Zig
- Durante años, la ZSF advirtió a Bun sobre el abuso de
comptime, y también creó una función de informe de tiempo para auditar el uso decomptime/inliney los tiempos de compilación
-
Velocidad de compilación
- Kelley señala que el artículo de Bun no mencionó la velocidad de compilación
- El proyecto del compilador de Zig tiene unas 600,000 líneas, un tamaño similar al de Bun antes de la reescritura
- En las mediciones de Kelley, compilar desde cero con caché limpia toma 16 segundos, y cada edición posterior, tras activar la compilación incremental, toma 90 ms
- Pregunta cuáles son las mediciones equivalentes de Bun después de la reescritura en Rust
Conclusión de Kelley
- Para Kelley, el problema central no son las funciones del lenguaje de programación, sino el colapso de la relación
- La ZSF agradece sinceramente las donaciones recibidas de Bun y usó ese dinero para compensar a contribuidores de Zig
- Kelley marca distancia diciendo que no pretende criticar maliciosamente a Jarred como persona
- Aunque Jarred tiene gustos y metas de vida distintos a los suyos, considera que logró construir con éxito la vida que quería
- Dice que acepta que Jarred es feliz y exitoso, y que no tiene mala intención
- Aun así, Kelley se alegra de que los intereses comerciales de la ZSF y Bun ya no estén entrelazados
- Cuando termine el debate público sobre si la reescritura en Rust fue buena o mala como criterio para elegir un lenguaje, también terminarán las interacciones entre ambas partes
2 comentarios
Después de leer el artículo, ya no me dan ganas de usar ni Zig ni Bun.
Comentarios en Hacker News
Aprendí muchísimo leyendo el código de Andrew y, como dice el texto original, sin Zig tampoco habría existido Bun
Sobre la parte que dice: “En el artículo afirma que hicieron fuzzing del código Zig, pero durante la llamada todo el equipo de Bun dijo que no hacían fuzzing de nada. Esto parece una manipulación descarada”, existe un PR de integración con Fuzzilli: https://github.com/oven-sh/bun/pull/24826
También hay PRs fusionados que corrigen problemas que Fuzzilli encontró en el código Zig de Bun: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
Si buscas “Fuzzilli”, aparecen más PRs: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...
zig build test --fuzz, es decir, al fuzzer integrado de Zig, y esa es la herramienta que cae dentro de su alcanceNo idolatro a ninguno de los dos; simplemente me da curiosidad porque toda la conversación parece empeorar en vez de ir en una dirección mejor
Que te den votos negativos por hacer una pregunta de verificación de datos es bastante significativo. Podría haber una respuesta simple como “hasta hace poco no usaban un fuzzer, así que ambos tienen razón”, pero pregunto porque no lo sé
Este texto es poco profesional y vergonzoso para Zig
Sé muy poco sobre Jarred, pero el texto suyo que leí ayer tenía un tono de agradecimiento hacia Zig, y ahora veo que además donó una suma considerable a Zig
Todo este texto lo ataca pública y personalmente por haber elegido otro producto
Si Andrew cree que este texto va a reivindicar a Zig, es raro; en realidad solo lo hace quedar infantil. O tal vez simplemente quiere atacar a Jarred
¿Todos tenemos que convertirnos en marcas ambulantes, filtrar siempre lo que decimos, caminar sobre hielo delgado y escondernos detrás de lenguaje corporativo para parecer “profesionales”?
El mundo necesita más discurso honesto, no menos, y las interacciones en línea parecen cada vez menos auténticas
Zig es, en la práctica, casi un proyecto de una sola persona, y esa persona está tomando decisiones cada vez más inestables
Por supuesto, es su proyecto y tiene derecho, pero una empresa valuada en casi billones no querría asumir este tipo de riesgo de cadena de suministro
Desde la perspectiva de Anthropic, en vez de invertir más en el ecosistema de Zig, conviene cortar de raíz cuando se evidencia el riesgo de que el not-so-BDFL se pase de la raya
En cambio, considerando su nivel de adopción y tiempo de desarrollo, Zig tiene una cobertura de pruebas vergonzosamente baja
La postura de Zig frente a la IA es completamente infantil. Podrían beneficiarse mucho, pero ni siquiera examinan ningún posible uso
Una cosa es intentar frenar el spam de PRs, y otra distinta es atarse de manos y no usar IA internamente ni siquiera en las áreas más fáciles y de mayor utilidad
También podrían usar IA para filtrar candidatos a bugs reales entre el spam de PRs, pero como no aceptan ninguna ayuda, bugs reales quedan sin atender más tiempo del necesario
Lamentablemente, hay demasiados desarrolladores de open source que se sienten demasiado cómodos escribiendo así, y esa es una de las razones por las que dejé de participar en open source
En un lugar de trabajo razonable, si te comportas así te despedirían o, como mínimo, te sancionarían
La frase “no hay crítica personal contra Jarred” es bastante fuerte para ponerla al final de un texto que casi en su totalidad parece una crítica personal apenas disimulada.
Es como decir que alguien tiene energía de principiante y envolverlo en una falsa positividad tipo “alguien que fracasa y aprende”, o escribir que, según rumores, lo llaman un “gerente apestoso”.
Se parece más a “no digo que sea malo, pero voy a escribir en el blog que todos están de acuerdo en que esta persona es mala”, y aunque fuera cierto, se ve de muy mal gusto.
Yo también trabajo con gerentes pésimos, pero no les guardo rencor personal.
“La red de rumores era grande y saludable, y estaba llena de uvas jugosas, y el jugo de esas uvas contenía todo el mismo mensaje: Jarred era un gerente apestoso”.
“Jarred ya escribía basura incluso antes de usar LLM”.
Es un texto extrañamente infantil. Me gustan los textos en los que alguien habla con franqueza, sin pasar por el filtro corporativo, pero esos textos también muestran cómo piensa y actúa esa persona.
Con un buen liderazgo, incluso si quitas el filtro corporativo, el resultado sigue siendo profesional; este texto revela algo muy por debajo de eso.
Cuando es seguro y no hay nadie dependiendo de ti, es completamente normal. Es distinto al trabajo de gestión.
Me llamó la atención la parte en la que ZSF suspiró aliviada cuando se completó la adquisición por parte de Anthropic. La cuenta ya estaba lista incluso cuando las donaciones se detuvieron discretamente, y tampoco se sorprendieron cuando no cancelaron la reunión mensual ni aparecieron. La relación ya estaba terminada.
He visto esto varias veces. Cuando adquieren un proyecto u organización, las “cosas buenas” que hacían no terminan con ruido, sino que simplemente desaparecen cuando el patrocinador empieza a ignorarlas en silencio.
Me alegra que hayan leído las señales y se hayan preparado. Es una gran lección que no hace falta aprender por las malas, y los proyectos libres y de código abierto que dependen de uno o dos grandes donantes deberían tener cuidado.
Creo que veremos mucho más de esto en el ecosistema de herramientas para desarrolladores.
En otras partes de este hilo hay reacciones duras al tono del texto, pero a mí este texto me quitó entusiasmo por Zig.
El drama es entretenido y la sinceridad de Andrew quizá sea respetable, pero esto no es el profesionalismo que necesita un proyecto serio.
Aunque parezca aburrido y poco inspirador, eso es lo que quiero en un stack tecnológico y en su operación: estabilidad.
Puede que Jarred haya sido una pérdida neta, pero Bun era un proyecto muy grande que usaba Zig, y que ese proyecto se vaya no es tan bueno para Zig como Andrew dice.
Parece que le da mucha más prioridad a la pureza y la ideología que al crecimiento del lenguaje. En un lenguaje de programación serio, la adopción y la masa crítica también son factores importantes.
Es parecido a decir que Linux no podía ser un proyecto serio por el tono de los correos de Linus.
Ni siquiera lo escribió de forma directa, fue un texto en su blog personal.
¿No es lo importante lo que ha aportado al lenguaje?
¿Por qué la adopción y la masa crítica tienen que ser necesariamente importantes? ¿Por qué no puede crear un lenguaje acorde con la pureza y la ideología que quiere, aunque eso implique renunciar a una adopción más amplia?
¿Por qué todo tiene que optimizarse para el crecimiento de usuarios y el reconocimiento?
Aunque ellos finjan que sí.
Este texto se sintió muy fresco. Debió haber sido muy tentador responder de forma más refinada al lenguaje de PR del texto de Bun, pero no lo hizo.
Podría haber incluido hechos que dejaran mal parado a Jarred mientras ocultaba con cuidado su propia opinión, por ejemplo: “escuché que la gente lo llama gerente apestoso. No digo que yo lo haga, otros lo dicen”, pero me gustó que fuera simplemente honesto.
El problema es que el contenido de esa personalidad y esos pensamientos es bastante difícil de aceptar.
Como el texto dedica su primera y mayor parte a ataques ad hominem especulativos, me cuesta confiar en lo que dice el autor.
Era una buena oportunidad para resumir las ventajas de Zig. Últimamente me habían dado ganas de aprender Zig por los textos evangelizadores e inspiradores de mitchellh, pero este texto me quitó las ganas de aprenderlo.
Se ve bastante sobre cómo Andrew percibe a Jarred, su forma de trabajar y su actitud laboral, pero no me queda claro qué es un ataque ad hominem ni qué es especulativo o no.
Los ataques personales contra Jarred no parecen ayudar mucho al argumento de usar Zig
Debió haberse centrado en el lenguaje, no usar expresiones como “mantenedor apestoso”
Sinceramente, al leer esto me dan ganas de evitar a Andrew tanto como a Jarred
También es algo que muchas personas de la comunidad han presenciado en los últimos meses
Decir “Jarred hizo que muchas personas de nuestra comunidad se fueran en su rol profesional, y queremos tomar distancia” no es lo mismo que decir “Jarred es una mala persona en privado”
Claro, en este ambiente, considerando cuánta vida privada fuera del trabajo habrán dejado los VC, puede percibirse casi como lo mismo, pero eso no es problema de Andrew
No defiendo el estilo de Andrew. Al hablarle a un público neurotípico más amplio, quizá podría haber ocultado un poco más su neurodiversidad
Aun así, es su proyecto, su comunidad ya conoce esa característica, y esto también es una variable conocida
Puede ayudar releerlo asumiendo que Andrew está siendo completamente sincero, sin atribuirle el subtexto secundario de que “Andrew intenta destruir la reputación de Jarred”
No es la primera vez que veo un texto suyo que me parece abiertamente malintencionado. No llega a ser algo que pueda llamarse eufemísticamente “directo”
“¿El silencio no era una opción?”
Aunque dice que “no hay críticas personales contra Jarred”, todo el texto se sintió como una crítica personal contra Jarred
Aunque fuera cierto, publicarlo de esta forma no es prudente. Si el objetivo era defender Zig, podría haberse hecho de una manera menos personal
Todo este trabajo de reescribir Bun de Zig a Rust parece una gran jugada de marketing
Si Anthropic AI de verdad es tan potente, ¿por qué no encargarle la tarea más ambiciosa de corregir bugs y rediseñar la base de código existente de Bun en Zig para que no solo se solucionen los bugs actuales, sino que tampoco vuelvan a aparecer bugs similares en el futuro?
Eso hirió los sentimientos de Anthropic
Puedo imaginar que Anthropic haya querido adquirir Bun incluso sin este artilugio
Unas semanas después, Bun empezó la reescritura en Rust. Aunque no se dijo explícitamente, creo que ambos hechos podrían estar relacionados
No sé cuál de las dos opciones es peor