El creador de Zig dice la verdad, pero Anthropic está exagerando

• Mientras Anthropic presenta el fin de la ingeniería de software como valor futuro, se critica que la transición de Bun de Zig a Rust también se haya usado en una narrativa promocional de que la IA puede reemplazar la ingeniería.
• Bun citó bugs de memoria como motivo del cambio, pero la falta de una comparación de alternativas, ventajas y desventajas, y el hecho de no revelar costos como la compilación lenta de Rust, puede parecer una justificación a posteriori.
• Había otras formas de operar Zig, y TigerStyle de TigerBeetle muestra un caso en el que se bloquea el use-after-free mediante asignación estática de memoria y pruebas de simulación.
• La migración archivo por archivo a unsafe Rust fue un enfoque razonable que redujo riesgos y permitió rediseños futuros, pero aceptar una conversión con IA a escala de un millón de líneas mientras se cuestionan unas pocas líneas de código de gestión de punteros legibles por humanos muestra poca coherencia.
• Como siguen siendo necesarios un harness para agentes, el borrow checker de Rust, reglas de legibilidad y revisión humana, adoptar agentes de codificación y descartar la ingeniería de software no son la misma elección.

---

El fin de la ingeniería de software que Anthropic promueve

• Anthropic impulsa activamente la narrativa de que, después de la programación, también desaparecerán la ingeniería de software y la mayor parte del trabajo humano.
• La compañía ha levantado 132 mil millones de dólares en inversión y se acerca a una IPO con una valuación de más de 1 billón de dólares, pero, al no poder demostrar rentabilidad, está en la posición de tener que vender una influencia futura hipotética.
• Por estos intereses, Anthropic debe verse como un narrador no confiable (unreliable narrator), y no solo importa la veracidad de su mensaje, sino también su impacto en el criterio de ejecutivos, líderes mundiales y administradores de fondos de pensiones.
• La narrativa de la IA influye en decisiones de arquitectura, producto y asignación de personal, y dificulta mantener la cabeza fría entre el miedo a los despidos, las advertencias de quedarse atrás y el Doom Trolling.
• Al evaluar la IA en el campo del software, hace falta un examen escéptico que tome en cuenta los intereses y objetivos promocionales de Anthropic.

La transición de Bun de Zig a Rust y la explicación tardía

• Anthropic/Bun recién explicó la decisión de trasladar Bun, escrito en Zig, a Rust dos meses después de fusionarla en la rama principal.
  • En un proyecto de infraestructura a gran escala, lo habitual sería explicar la dirección de antemano.
  • Mientras la explicación se demoraba, títulos como Anthropic’s Bun Rust rewrite merged at speed of AI difundieron la impresión de que la IA había completado rápidamente la reescritura.
• Andrew Kelley, creador de Zig, publicó una réplica y, en un tono inusualmente directo, criticó la tecnología y la operación organizacional de Bun.
  • Existe un costo reputacional, porque puede sentar un precedente en el que el líder del lenguaje anterior ataque incluso defectos personales solo porque se cambió de lenguaje.
  • Algunos lo llamaron “meltdown”, pero también cabe verlo como el señalamiento público de problemas que debían discutirse.

Criterios para juzgar una crítica directa

• El habla correcta (right speech) del budismo sostiene que toda afirmación debe cumplir cinco criterios:
  • ¿Es verdadera?
  • ¿Es útil?
  • ¿Es oportuna?
  • ¿Es amable?
  • ¿Parte de la amabilidad?
• La respuesta de Andrew Kelley corresponde a palabras verdaderas pero poco amables, y el punto en disputa es si era necesario señalar públicamente el problema aun saliéndose de la cortesía habitual.

La relación entre Bun, Zig y las políticas de contribuciones con IA

• Bun es un runtime de TypeScript comparable a un NodeJS más rápido, y Zig es un lenguaje de programación de sistemas comparable a un C moderno.
• Hasta hace poco, Bun estaba escrito en Zig y era una de las bases de código más grandes en Zig.
• Las políticas de contribuciones con IA de ambos proyectos son totalmente opuestas.
  • Bun afirmó que las contribuciones de código son casi 100% IA.
  • Zig no permite contribuciones de IA.
• Después de que Anthropic adquiriera Bun, su fundador Jarred Sumner realizó un experimento a gran escala con agentes para trasladar el código Zig a unsafe Rust, y el resultado se fusionó unos días después para convertirse en la versión oficial.
• Entre las partes relacionadas no parece haber nadie que exija mantener Bun en Zig; la controversia se centra más en los motivos y la forma de promocionar el cambio que en la transición en sí.
• Una migración de lenguaje a gran escala mediante agentes es un experimento técnico que, en las circunstancias adecuadas, vale la pena volver a intentar.

Tres interpretaciones de una misma decisión

• Para los desarrolladores que buscan elegir entre Zig y Rust, que uno de los mayores usuarios de Zig haya revertido su decisión se vuelve un dato importante para evaluar.
• La interpretación de Anthropic/Bun es que probaron todos los métodos razonables, pero con Zig era difícil manejar los bugs de memoria.
• Según la interpretación de Andrew Kelley, la base de código se volvió un desastre por decisiones de ingeniería de Bun, como delegar en exceso la escritura y revisión de código a agentes de IA.
• Una posibilidad más común es que hubiera varias soluciones para problemas reales de memoria, pero que para la dirección fuera más fácil elegir una reescritura en Rust.
  • Podían promocionar las capacidades del nuevo modelo Fable.
  • Anthropic ya usaba Rust.
  • El proyecto Zig se opone públicamente al uso de productos de Anthropic.
• La transición a Rust puede ser razonable desde el punto de vista del negocio, pero la promoción se enfocó en que la IA era lo bastante potente como para realizar la reescritura.
  • El hecho de que la IA no haya detectado de antemano los use-after-free entra en conflicto con esa narrativa.
• La exageración a través del megáfono de Anthropic fuerza una comparación directa entre el criterio de Jarred Sumner y el de Andrew Kelley, y puede afectar de manera no intencional la reputación de Zig.

Por qué la credibilidad personal entró en una discusión técnica

• El primer actor al que debe pedirse responsabilidad no es el fundador de Bun como individuo, sino Anthropic, que usa este caso en la narrativa de IA.
• Dado que Anthropic utiliza la credibilidad de Jarred Sumner para reforzar su propio mensaje, responder a eso obliga a evaluar también su criterio y sus acciones.
• Sería preferible discutir solo los aspectos técnicos, pero si el mensaje de Anthropic depende más del espectáculo y la promoción que de una comparación técnica, la credibilidad personal también termina entrando en la controversia.
• Si solo ordenar lo que una parte dijo e hizo públicamente parece difamatorio, esas acciones en sí mismas pueden ser parte del problema.

Crunch permanente y el entorno organizacional de Bun

• El anuncio de empleo de Bun de 2022 advertía que los primeros nueve meses serían muy duros y que no era un lugar adecuado para quienes valoraran un equilibrio entre vida y trabajo con mucho tiempo sin trabajar.
• El modo crunch permanente perjudica tanto la salud como la productividad, algo que también se confirma repetidamente en estudios empíricos sobre trabajo del conocimiento.
  • Como material relacionado, puede consultarse la sección Human Factors de Empirical Software Engineering.
• Hay que elegir a managers que protejan a sus equipos para que puedan dormir por la noche, no a quienes presumen de trabajar 90 horas por semana.
• La evaluación que Andrew Kelley dice haber escuchado de personas relacionadas con el equipo de Bun se resume en falta de comunicación, expectativas poco realistas, baja empatía y falta de experiencia, aunque tiene la limitación de ser información de segunda mano.
• Aun así, esa evaluación coincide con el entorno laboral extremo que se hizo público en el anuncio de empleo.
• Incluso en malos entornos de trabajo pueden surgir tecnologías excelentes, y Bun en sí es una herramienta útil e interesante.
• La evaluación de que el código tenía muchos bugs y era difícil de mantener no es solo una crítica externa; también es el estado que Bun presentó como fundamento para su transición a Rust.

Valor práctico del enfoque de portabilidad con unsafe Rust

• Vale la pena reutilizar los detalles técnicos del proceso de transición en otros proyectos de modernización
• Bun no se rediseñó desde cero en Rust seguro, sino que realizó una portabilidad archivo por archivo a unsafe Rust
  • Mantuvo la estructura existente para reducir el riesgo inicial de la transición
  • Sentó las bases para mejorar la seguridad y rediseñar después
• La automatización basada en IA podría hacer que elegir un lenguaje sea más reversible que antes, pero la reescritura automática aún tiene ventajas, desventajas y diferencias semánticas
• También es posible combinar varias técnicas de reescritura y reforzarlas con métodos formales (Formal Methods)
• TRACTOR, de DARPA, es un programa de investigación para trasladar todo el código C a Rust, y el informe de evaluación publicado aborda el estado actual de la tecnología de conversión automática
• Aunque los agentes ofrezcan más opciones para código antiguo, seguirá haciendo falta criterio y comunicación para definir los objetivos de modernización
  • Una referencia relacionada es Kill It With Fire, de Marianne Bellotti

Un documento de decisión técnica con muchas omisiones

• Para explicar una decisión técnica se necesitan al menos tres elementos
  • Cuál es la motivación
  • Qué alternativas se evaluaron
  • Cuáles son las ventajas y desventajas de cada alternativa
• El documento en el que Richard Feldman resumió por qué trasladó el compilador de Roc de Rust a Zig es un caso comparativo que incluye los tres elementos
• La explicación de Bun presentó como motivación los bugs de memoria, pero solo cubrió parcialmente las alternativas evaluadas y, en la práctica, omitió la comparación de ventajas y desventajas
• En particular, omitir las ventajas y desventajas puede hacer que parezca una justificación a posteriori, en la que primero se fija la respuesta correcta y luego se le agregan fundamentos
• Tampoco puede descartarse que existan otras razones no publicadas; para aumentar la credibilidad de la decisión, también deberían transparentarse los costos desfavorables

Una comparación que solo enumera las ventajas de Rust

• La sección “Bun is better in Rust” trata solo los beneficios de pasar a Rust y casi no presenta costos
• Una base de código grande en Rust suele pagar el costo de tiempos de compilación lentos a cambio de seguridad
• En el pasado, Bun consideró importante la velocidad de compilación e intentó mejorarla 4 veces mediante un fork del compilador de Zig
• Si la portabilidad a Rust aumentó el tiempo de build de los contribuidores, debería publicarse, y explicar por qué la seguridad es más importante que ese costo aumentaría la credibilidad de la decisión
• Al mezclar otras mejoras realizadas después de la transición en la lista de ventajas de la reescritura en Rust, puede exagerarse el efecto directo del cambio de lenguaje

Opciones de guía de estilo no evaluadas

• En Bun, los bugs de memoria no eran la única causa de fallas, pero según un recuento personal eran lo bastante frecuentes como para requerir 4 commits de corrección por semana
• Cada bug de memoria significa que en algún punto se rompió una convención sobre cómo se crean, poseen y liberan los objetos, por lo que primero podría evaluarse un método para definir con claridad el comportamiento esperado en cada situación
• La gestión manual de memoria amplía el alcance de las convenciones, pero independientemente del lenguaje se necesitan guías de uso efectivas, y Rust también tiene guías de estilo de API

• La alternativa que muestra TigerBeetle

  • TigerBeetle, otra base de código representativa en Zig y una base de datos para transacciones financieras, no sufre bugs de memoria y parece ser una de las bases de datos más confiables
  • Usa TigerStyle y pruebas de simulación como base de su confiabilidad
  • TigerStyle no es una simple convención de formato, sino una filosofía de ingeniería que une diseño, memoria y pruebas
  • Toda la memoria se asigna estáticamente al inicio
  • Después de la inicialización no se permite la asignación dinámica ni la reasignación después de liberar
  • Bloquea los use-after-free al mismo tiempo que evita cambios de rendimiento difíciles de predecir
  • Al considerar desde la etapa de diseño los patrones posibles de uso de memoria, impulsa estructuras más simples, rápidas y fáciles de razonar y mantener
  • No todas las aplicaciones pueden aplicar este enfoque tal cual, pero muestra que la política de memoria está conectada con las decisiones de diseño generales

• Vacíos que quedan en la explicación de Bun

  • Bun mencionó TigerStyle y la guía de estilo de C++ de Google de 31,000 palabras, y luego resumió que las guías de estilo son difíciles de hacer cumplir y que tradicionalmente se depende de revisiones de código, linters y analizadores estáticos
  • Sin embargo, no aborda qué guía de estilo usó realmente Bun, por qué falló ni cómo la mejoró durante 4 años
  • Si en un proyecto grande persistieron los problemas de memoria, es importante saber si se probaron seriamente opciones para usar el lenguaje actual de otra manera, pero faltan fundamentos que lo respalden
  • Un modo de operación en el que una sola persona mantiene todo el contexto en la cabeza y no se hacen reuniones dificulta crear convenciones explícitas y un diseño compartido

La contradicción entre las revisiones de agentes y las guías de estilo

• Bun sostiene que las guías de estilo son difíciles de hacer cumplir, pero también afirma que escribió un PORTING.md para la migración y que los agentes revisaron toda la reescritura siguiendo lineamientos estrictos
• Como PORTING.md en sí mismo es una guía de estilo específica para el alcance de la transición, si la revisión de agentes fue exitosa, entonces el problema de hacer cumplir los lineamientos ya quedó resuelto
• En condiciones adecuadas, las revisiones con agentes pueden funcionar, pero requieren reglas y métodos de revisión suficientemente diseñados
• Ese mismo esfuerzo mental podría haberse invertido en rediseñar el código Zig y reforzar sus convenciones, pero Bun eligió reescribir en lugar de rearquitecturar
• Por varias razones no publicadas, la reescritura podría haber sido la opción correcta, pero con la explicación actual no alcanza para comparar alternativas

Una reescritura de un millón de líneas y tres líneas de código de punteros

• Bun considera que, para expresar a nivel de tipos las expectativas de propiedad en Zig, habría que agregar código como SharedPtr(TCPSocket) y deref(), lo que resulta menos cómodo que el uso existente de punteros
• En este ejemplo, se agregan aproximadamente tres líneas de código para aclarar el paso de punteros en los límites de la interfaz
• Aceptar un PR generado por IA de un millón de líneas difícil de revisar, pero rechazar unas pocas líneas que aclaran la propiedad de punteros por problemas de legibilidad, es una postura poco consistente
• Jarred Sumner dijo que durante meses nadie ingresó código manualmente
• Si el código no es para humanos, la razón de que el wrapper SharedPtr sea incómodo de leer pierde fuerza; si es para humanos, entonces hay que seguir considerando la legibilidad, la posibilidad de revisión y la mantenibilidad
• Las empresas de IA se resisten a admitir que la legibilidad del código sigue siendo importante, pero negar esto puede encajar con la narrativa de que la ingeniería de software se acabó, aunque choque con la realidad del mantenimiento
• También hay benchmarks que indican que los agentes de coding pueden empeorar la mantenibilidad por defecto

Lo que revela este mismo caso: “solo con IA no alcanza”

• La reescritura a gran escala de Bun mediante agentes no solo implica una mejora técnica, sino que también cumple una función comercial para promover el mensaje de Anthropic de que “con IA basta”
• Sin embargo, el mismo caso también puede interpretarse de forma totalmente opuesta
  • Como los LLM por sí solos no alcanzan, se los envuelve en un arnés de agentes
  • Como la IA por sí sola no puede garantizar la seguridad de memoria, se eligió el borrow checker de Rust
  • Como las personas tienen que leerlo, preocupa la legibilidad de los wrappers de punteros
  • Como las personas tienen que mantenerlo, se enfatiza una estructura de código familiar y similar a la existente
  • Project Bunsen encontró 50 errores en la versión de Bun en Zig mediante un enfoque híbrido
  • Los mantenedores de open source están respondiendo a la carga que genera el slop de IA, los problemas para verificar colaboradores, las políticas para filtrar contribuciones de IA y la reorganización de políticas sobre IA generativa
• Bajo la premisa de que incluso los problemas creados por agentes pueden resolverse con más agentes, se está extendiendo la práctica de comprar tokens en lugar de mejores herramientas y de adjuntar SKILL.md en lugar de aprender la tecnología
• Llamar Team a sesiones paralelas de agentes, en vez de comprender la psicología de los equipos de software, confunde las organizaciones humanas con sesiones de ejecución automática

Adoptar agentes de coding y descartar la ingeniería son cosas distintas

• La campaña de Anthropic sobre el fin de la ingeniería de software puede ser contraproducente tanto para quienes crean herramientas de IA como para quienes las usan
• Aunque se adopten agentes de coding, no hace falta tomar como modelo ideal una Dark Software Factory en la que las personas no entienden el código
• El objetivo es construir lo que la gente quiere y hacer que funcione correctamente; la burbuja de la IA puede presionar para crear cosas no deseadas y de baja calidad
• Hace falta un rumbo que aproveche la IA sin renunciar al criterio, el aprendizaje, la comunicación, la legibilidad y la mantenibilidad

[linusjeh]

La IA sí puede ser buena con Rust. Solo que consume muchos tokens... me parece una decisión muy propia de Anthropic.

[paruaa]

Cambió respecto de lo que esperaba al entrar a leer el artículo, pero como se habla tanto de memoria, entiendo por qué tomaron esa decisión. Al final, parece cierto que gestionar la memoria manualmente aumenta la probabilidad de cometer errores al usar IA. Si eligieron simplemente usar Rust para detectar esos problemas en tiempo de compilación y así poder aprovechar mejor la IA, se entiende. Independientemente de programar con IA, claro.

[hmmhmmhm]

¡Viva Rust, viva por siempre!

[GN⁺]

Comentarios de Hacker News

• Este texto tiene muchos puntos buenos, pero me hace pensar en proyectos generados por IA que se abandonan a los pocos meses. El valor de un proyecto no está en la cantidad de código generado, sino en cuánto se ha validado en producción, y un código existente y maduro es mejor que una reescritura nueva
  La base de código existente de Zig ya está validada, pero la reescritura en Rust, fuera de pasar tests, tiene una validación cercana a cero, y si se hizo una traducción casi literal archivo por archivo con unsafe Rust, ni siquiera queda claro qué mejora aporta respecto al Zig original. Solo tendrá sentido cuando luego se lleve a Rust seguro y se valide en entornos de producción y con muchos usuarios
  En la práctica, Bun terminó bifurcado, pero da igual cuál sobreviva, si la versión en Zig o la de Rust, y tampoco hay motivo para tomar esto como una señal de que Zig no es adecuado

  • Los proyectos con IA se abandonan porque se generan de forma impulsiva. El costo hundido incluso puede ser una ventaja para soportar la adversidad y los periodos de estancamiento, pero un resultado hecho solo con una idea momentánea y prompts para Claude no genera apego
    Incluso yo, como programador común, tengo decenas de ideas geniales todos los días, pero muy pocas resisten un análisis serio, y a los pocos días hasta esas dejan de parecerme dignas de esfuerzo. Las ideas siempre fueron baratas, y ahora hasta la prueba de concepto es barata, así que no me interesa un Show HN al que ni siquiera se le invirtió un mes
  • Para llegar a un Rust seguro que haya pasado por una validación real considerable, hay que empezar en algún punto, así que la idea fue hacer primero una traducción literal e ir mejorando gradualmente
    La gente de Zig parece preocupada por si Zig será un lenguaje sin futuro desde el inicio, ya que no ofrece suficientes ventajas frente a C para usos serios y hasta su proyecto más representativo se fue. Si buscas segfault en el issue tracker de Zig, se entiende por qué algunos dudan de su utilidad futura frente a alternativas como Rust
  • A diferencia de Zig, ahora sí hay límites unsafe claros y acotados, y eso es mejor porque se pueden ir corrigiendo uno por uno
  • La introducción del texto es demasiado cínica. Por conocidos que tengo en Anthropic y OpenAI, ellos realmente creen que en un futuro cercano los agentes harán la mayor parte de la programación y que ellos mismos perderán sus empleos
    No están gestionando el mensaje para darle una lección al bando anti-IA
  • No se puede afirmar con certeza que los proyectos generados por IA se abandonen rápido por falta de validación en producción. La mayoría de los proyectos personales normales también se abandonan con el tiempo, y puede que, al poder escribir código mucho más rápido, se llegue antes al punto de rendimientos marginales decrecientes en utilidad personal, aprendizaje y diversión

• Más que el hecho de que Andrew hablara sin rodeos, el mayor problema es la doble actitud de afirmar que el texto no es un ataque personal cuando claramente sí lo es
  Después de leer esto, ya no me dieron ganas de construir nada con Zig. Cualquier decisión técnica que tomes queda bajo un lenguaje cuyo BDFL vitalicio puede escribir algo así, y cuesta imaginar a la dirigencia de otras comunidades como Python o Rust comportándose de esta manera

  • Más grave aún es que parece haber señales de que esa actitud se está extendiendo en la comunidad de Zig. Aunque todavía no sea la mayoría, si la gente amable se va a comunidades más cálidas, ese tipo de perfil terminará pesando más entre los que se queden
  • Quiero defender a Andrew diciendo que tiene posturas firmes porque de verdad le importa hacer lo correcto, pero que es una persona más paciente e inclusiva de lo que parece cuando uno juzga desde lejos
    Alguien puede ver que Andrew atacó a Bun, y yo puedo ver las reacciones hacia Andrew como ataques personales. Si uno deja de lado sus prejuicios, habría que concluir que ambos lados actuaron mal o que ninguno lo hizo, y al juzgar una situación desde lejos hay que ser consciente de cuánto influyen los sesgos personales
  • Si te vas, mientras no publiques textos engañosos que hagan quedar mal a Zig y no faltes sin avisar a reuniones ya agendadas con la fundación Zig, no habría problema
  • El texto de Andrew fue editado varias veces, así que tal vez leer la versión más reciente despeje algunas preocupaciones: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
  • En Rust no hay un BDFL por diseño, y recuerdo que Python también dejó atrás ese modelo. Puede haber contribuyentes individuales que escriban textos agresivos estando enojados, pero no existe una sola figura que represente al lenguaje como en Zig

• Quiero ponerme del lado de Andrew. Habiendo seguido el trabajo de Sumner durante años, la crítica de Kelley, aunque poco amable, era en gran parte cierta, y aunque el resultado sea útil y genial, de principio a fin se pareció más a un ejercicio de influencia para autopromoción
  Yo también llevo desarrollando 8 horas al día con agentes y recomendando a mi equipo usar Rust y Deno en lugar de Node, pero esta reescritura tenía una justificación muy débil y parece una continuación de la larga campaña promocional que Dario y compañía lograron impulsar. Si lo hubiera expresado de forma más diplomática, probablemente lo habrían recibido mejor, pero valoro que haya compartido lo que realmente pensaba en vez de publicar un texto redactado por el equipo de PR

  • La lección que deja todo este lío es que, antes de publicar una respuesta encendida, hay que dejarla reposar 1 o 2 días y mostrársela a un amigo cercano. Habría sido mejor que Andrew publicara desde la primera revisión algo más parecido a la conclusión que luego corrigió
  • La justificación previa de la reescritura era débil, pero aun así se entendía por qué Jarred estaba frustrado, incluso sin ejemplos
    Fue útil la explicación de que interactuar con el recolector de basura de JavaScript genera dificultades particulares en Bun, pero Andrew no trató ese punto en absoluto. También ayudó la aclaración de que el código nuevo se validó con la suite de tests existente, porque eso corrigió la impresión equivocada de que hasta los tests habían sido traducidos con vibe coding y por eso no eran confiables. Que los tests no detecten todos los bugs aplica a todo el software, incluido Zig
    Al final, esto se expandió por el choque entre la visión de que los lenguajes sin seguridad de memoria generan costos enormes por defectos y la respuesta de “mejora tu habilidad y no escribas bugs”, sumado al debate sobre IA, la participación de Anthropic y el estilo a lo Linus de Andrew
  • La idea misma de que haya que justificar una reescritura ante gente ajena a la empresa me parece rara
  • En temas técnicos, prefiero la actitud de Linus de decir las cosas como son antes que el lenguaje de PR, y las frases promocionales deberían reservarse para clientes no técnicos

• Me pregunto si realmente leyeron el texto de Anthropic y el de Andrew Kelley de la misma manera. Anthropic no es una empresa que vende lenguajes de programación, y el artículo sobre la reescritura de Bun en Rust tenía muchos detalles técnicos que mostraban cómo mejoró el producto para el usuario final.
  En cambio, la respuesta del lado de Zig se parece más a una columna mordaz llena de ataques personales. Yo uso Codex y no tengo intereses ni en Zig ni en Rust, así que lo observo desde fuera.

  • Anthropic claramente también tiene intereses en el mercado de lenguajes de programación. Si la IA hace más fácil reescribir hacia cierto lenguaje, las historias de éxito vinculan ese lenguaje con la empresa de IA, y el éxito de Rust como lenguaje fácil de escribir con IA también beneficia a Anthropic.
    Además, cuando se promociona una reescritura exitosa, muchas veces se ocultan elementos que perjudican la narrativa, como qué tan malo era el código anterior, y aquí también faltaron aspectos importantes.
    El texto de Andrew Kelley(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) trata sobre los bajos estándares de ingeniería de Jarred, sus malas relaciones externas, incluyendo ausencias sin avisar a reuniones con la fundación Zig, el daño causado al presentar a Zig como una mala elección durante la transición a Rust, y la indignación de la ZSF por todo eso.
    Visto superficialmente, uno podría preocuparse de que el creador de un lenguaje esté atacando a un exusuario, pero Kelley explicó por qué esa impresión, que yo también tuve tras leer solo el texto de Bun, es injusta. Algunos ataques personales sí están presentes, y él mismo los aborda en la última sección agregada después.
  • Si imaginamos que un estudio cambia de Unity a Unreal y luego Unity publica un texto atacando la calidad del código previo y el ambiente laboral, ya de por sí resulta extraño que Zig haya respondido así.
  • Este es un viejo choque entre artesanía e industrialismo. Andrew pertenece a una tradición que quiere que todo desarrollador sea un artesano orgulloso de su trabajo.
    Java, JavaScript, Python y C# dominaron la industria centrada en C++ porque ofrecen barandales de seguridad para que incluso desarrolladores no perfeccionistas puedan trabajar sin causar desastres mayores. C y C++ tenían grandes ventajas de rendimiento, pero exigían mucha habilidad en un entorno cada vez más hostil.
    Rust y Swift ofrecieron una predictibilidad de rendimiento mayor que los lenguajes con recolección de basura, junto con una seguridad similar o más fuerte, y las ideas de Rust hicieron que aparecieran explosivamente nuevos lenguajes en ese espacio. Eso sí, muchos de ellos están más cerca de la artesanía que Rust, que partió de necesidades industriales.
    Si usamos una analogía con vehículos, Java y JavaScript son autos seguros de uso general, C/C++ son motocicletas de dos ruedas, Rust es un auto de rally rápido que protege a sus ocupantes, y Zig se parece más a una cuatrimoto o a un kart de ruedas descubiertas. No es fácil que derrape, pero si vuelca es muy peligroso.
    Los artesanos que ignoran las restricciones de tiempo y costo creen que basta con tener desarrolladores cuidadosos, pero en la industria, aunque uno pueda escribir buen código, el 90% del trabajo se hace bajo restricciones, así que cuesta confiar tanto en mi código como en el ajeno. Zig tiene muchas ventajas, pero desde el principio fue un lenguaje para gente que prefiere la libertad de hackear antes que la seguridad.
  • Las mejoras en tamaño del binario y velocidad no tienen mucha relación con la reescritura en Rust en sí, y algo similar probablemente se habría podido lograr invirtiendo el mismo esfuerzo en la base de código de Zig. Hubo también trabajo adicional para que esos números se vieran bien al promocionar la reescritura.
    La seguridad de memoria quizá también se habría podido lograr de forma parecida si, en lugar de IA, pruebas y fuzzing de nivel superior, se hubiera usado el fuzzer integrado que recomienda el equipo de Zig. Aun así, para un proyecto como Bun, puede que Rust, más maduro, sí sea una mejor opción.
    La perspectiva de Andrew fue esencial para entender qué pasó. Algunas expresiones podrían haber sido más suaves, pero si una mala gestión fue la causa directa del deterioro de la relación y de malos resultados de ingeniería, señalarlo no es un ataque personal sino contexto necesario.
  • Considerar que un producto orientado a aumentar la productividad de los programadores escribiendo código por ellos no tiene relación con el mercado de lenguajes solo porque no venda su propio lenguaje es una visión bastante miope.
    Sobre todo porque el liderazgo de Zig ha expresado públicamente su rechazo al vibe coding y ha criticado a la industria, y el proyecto está rechazando contribuciones hechas con ese producto.

• En esta discusión, lo que falta es justamente sustancia técnica. No me interesa la migración de Bun a Rust, ni el texto agresivo de Andrew, ni Anthropic vendiendo palas en una fiebre del oro; quiero ver contenido técnico concreto.
  Las razones que Jarred dio para pasarse a Rust parecen razonables aunque estén algo poco fundamentadas, pero Andrew no refutó por qué eso no sería un problema real ni cómo se resolvería correctamente en Zig. En especial, quisiera que el punto se analizara con base en el código real de Bun en Zig.

  • Viendo solo los hechos presentados por Bun, la solidez técnica de la reescritura es insuficiente, lo cual no sorprende, porque en la mayoría de los casos reescribir es mala ingeniería.
    Bun fue iniciado por alguien con poca experiencia en Zig, a pesar de su enorme alcance y complejidad, y desde el principio era un proyecto que reescribía código de otro lenguaje. Si la historia fuera que esbuild hubiera trasladado línea por línea su transformador de JavaScript y TypeScript de Go a Zig, y luego tras unos años hubiera desechado toda la base de código para reescribirla otra vez en otro lenguaje, cuesta ver qué más habría que discutir.
  • El punto central de Andrew es que el código de Bun ya era malo desde el origen, y se puede leer como una insinuación de que Jarred es una persona tan tóxica que ni siquiera vale la pena entrar en debate con él.
  • Bun quiere moverse rápido y romper cosas, mientras que Zig te empuja a moverte lento y con cuidado.
    Bun quiere lanzar cuanto antes funciones como un lenguaje de shell o clientes para SQLite/PostgreSQL, así que no quiere preocuparse manualmente por la gestión de memoria. Zig te obliga a lidiar directamente con la memoria y los tiempos de vida, y deliberadamente no añade algo como Drop, mientras que Rust encaja mejor precisamente gracias a Drop.
    Igual que no harías una base de datos SQL en Python, Zig no es la herramienta adecuada para Bun, y esto no es tanto un tema de cómo resolverlo correctamente en Zig, sino una diferencia en la forma en que Jarred quiere llevar el proyecto a toda velocidad.
  • El texto original sí toca este tema, pero de forma muy selectiva y casi solo mostrando lo positivo. Por ejemplo, dice que hasta reescribieron el compilador de Zig para mejorar los tiempos de compilación, pero entonces queda la duda de por qué no se habló en absoluto de los tiempos de compilación de Rust, que por lo general son mucho peores.
  • Quienes venden palas en una fiebre del oro son las empresas que construyen centros de datos y energía, y los tokens serían el oro.

• Coincido con parte de lo que dice Kelley, pero el problema es el tono.
  Si Bun se hubiera reescrito de Rust a Zig, es poco probable que un miembro central del equipo de Rust hubiera publicado un texto con ataques personales dirigidos a Sumner mientras insistía en que no eran ataques. Kelley tiene libertad para escribir el texto que quiera, pero la gente también tiene libertad para reaccionar ante la imagen pública de Zig creada por el BDFL de un lenguaje en crecimiento.

• El texto sobre el cambio de Bun a Rust omitía comparaciones concretas entre opciones y cifras de impacto, y trataba el resultado de forma sesgada, así que no se sintió como una entrada de blog de ingeniería
  Parecía que a la gente le interesó más el uso de agentes que la justificación técnica de la migración, y en lo técnico fue muy decepcionante

  • Me pregunto si leímos el mismo texto. No trataba una línea de código específica, pero repetidamente incluía detalles profundos de arquitectura, fundamentos sobre seguridad de memoria y bugs, y patrones de coding con agentes a gran escala

• No hay que subestimar la influencia del marketing sobre gerentes y ejecutivos, especialmente lo fácil que incluso personas en cargos como CEO pueden dejarse llevar por emociones triviales
  Solo por ser una oportunidad para promocionar el nuevo modelo Fable y porque Zig se opone públicamente al uso de productos de Anthropic, puede que la reescritura de Bun en Rust ya estuviera prácticamente decidida

  • No entiendo por qué asumir que la dirección intervino de alguna forma. Parece mucho más plausible que Jarred simplemente hiciera lo que quería hacer, y él mismo ha dicho eso

• No sé por qué en una discusión sobre cambiar de lenguaje también se está hablando de expectativas sobre horas de trabajo. Aunque él sea un mal gerente, parece que están forzando la búsqueda de material negativo
  También es revelador que desde el lado de Zig casi no se enfoquen en las ventajas técnicas de la reescritura en sí. Anthropic presentó varias mejoras, pero es difícil encontrar siquiera un intento de refutarlas
  Si al reescribir mi proyecto con un modelo de lenguaje grande el resultado fuera una mejora sin desventajas, me preocuparía bastante y reaccionaría, pero aquí están hablando de horas de trabajo, algo totalmente fuera de lugar

• Hay un claro conflicto de interés entre un proyecto propiedad de Anthropic y la dirigencia de una comunidad de lenguaje que es públicamente hostil al código generado por IA
  Habría sido mejor que Andrew Kelley se limitara a decir solo eso y se detuviera ahí; su evaluación sobre la energía y motivaciones del fundador de Bun aporta muy poco

  • Es difícil que lleguen a un punto medio quienes apoyan o se oponen a la IA de forma absoluta. La mayoría de los argumentos y ataques técnicos son racionalizaciones a posteriori; cada organización solo tiene contextos y objetivos distintos
    Kelley también lo sabía, pero parece que no pudo resistir la tentación de enturbiar el punto central. El texto agresivo ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) se pasó de la raya, pero el apéndice que llama a seguir adelante es sensato. Creo que es mejor que un BDFL sea algo picante a que sea demasiado insípido