Bun reescrito en Rust: cuando la pugna sectaria ahoga el debate técnico

Se armó un buen chismarajo en el mundo de los lenguajes de sistemas. Bun —el toolchain de JavaScript que empezó como un port línea por línea del transpilador de esbuild— fue reescrito de Zig a Rust. Lo escribió, hasta donde entiendo, un solo ingeniero orquestando a Claude, tras la adquisición de Bun por parte de Anthropic. Jarred Sumner cuenta el cómo y el porqué en un post extenso y bien armado: 64 instancias de Claude corriendo en paralelo durante 11 días, revisión adversarial con contextos separados, más de un millón de líneas, unos 165.000 dólares en cómputo, y la test suite de siempre —escrita en TypeScript, ajena al lenguaje del runtime— como red de seguridad.

Como todo cambio radical, produjo descontento. Los partidarios de Zig hablan mal de Rust; los de Rust se sienten validados y hablan mal de Zig. Lo de siempre: sentimiento partidista disfrazado de tecnología. Lo que me pareció digno de comentario fue la respuesta de Andrew Kelley, creador de Zig.

El argumento existía; el ruido lo tapó

Seré justo, porque conviene serlo: Kelley sí trae argumentos técnicos. Sostiene que la dicotomía que plantea el post de Bun —o guía de estilo, o feature del lenguaje— es un falso dilema, y que los bugs se eliminan sobre todo dedicando recursos de ingeniería a cazarlos, como hace TigerBeetle. Señala una tensión real: si la test suite no bastaba para atrapar los bugs del código Zig, ¿por qué habría de bastar para blindar un millón de líneas generadas por una máquina y sin revisión humana línea a línea? Recuerda que el LTO siempre estuvo disponible en Zig, que buena parte del ahorro de tamaño de binario es ortogonal al cambio de lenguaje, y que el post evita mencionar la velocidad de compilación. Son objeciones legítimas. Ahí hay debate.

El problema es todo lo demás. Esos argumentos van envueltos —y quedan subordinados— a una biografía descalificadora: el “beginner energy”, el retrato de mal gerente construido a partir de rumores de pasillo, el diagnóstico de que Jarred “escribía slop” desde antes de tener LLMs, el mote “RoboBun”. Cuando terminas de leer, no recuerdas el punto sobre el LTO: recuerdas la taza de té imaginaria que dice “It Tastes Like It’s Not My Problem Anymore”.

Y ese es exactamente el fenómeno que vale la pena nombrar. La discusión técnica se ahoga bajo la pugna sectaria, y suele hacerlo justo cuando el argumento técnico, por sí solo, no alcanza para cerrar el caso. Si tus objeciones fueran contundentes, no necesitarías el retrato psicológico del adversario. El ataque a la persona no es un complemento del argumento: es lo que se pone en su lugar cuando el argumento no basta. El texto tiene, para mí, la cadencia de un líder que, ante una ruptura, dedica más energía a explicar por qué el disidente nunca fue de los nuestros que a rebatir lo que hizo. Es una táctica que he visto en organizaciones políticas y religiosas frente al riesgo de desbandada: se blinda al rebaño desacreditando al que se fue.

Qué irradia un buen líder de proyecto

Un líder técnico irradia confianza a través de cualidades concretas: sensatez, serenidad, foco en atender la crítica y capacidad de autocrítica. No hace falta ser tibio para tenerlas. El paradigma del “dictador benevolente” —pienso en Linus Torvalds— demuestra que se puede ser vehemente, incluso soez, y seguir siendo un líder confiable. La clave no es el tono: es el origen. Las descargas de Torvalds, con todo su exceso (y sí, hubo excesos por los que después pidió disculpas), parten casi siempre de una afirmación técnica verificable: este parche rompe esto, por esta razón. La furia está anclada a un hecho, no a la biografía del autor.

El texto de Kelley invierte ese orden. Abre con el carácter de la persona y llega al código casi de reojo, y cuando llega, la emotividad agresiva no se disipa: sigue impregnándolo todo. No es un abordaje técnico contaminado por algo de emoción; es un ajuste de cuentas emocional al que se le agregaron, casi como coartada, unos cuantos puntos técnicos.

Lo revelador es el contraste con el propio post que critica. El escrito de Sumner —más allá de que sea, como bien apunta Kelley, una pieza de marketing pulida por una empresa con mucho en juego— modela precisamente las virtudes que uno espera de un líder: agradece a Zig sin ambigüedad (“Bun no habría sido posible sin Zig”), no culpa al lenguaje de sus propios bugs, documenta 19 regresiones que él mismo introdujo y luego corrigió, y cierra con un lema que debería enmarcarse: “Boring is good”. Cuesta acusar de soberbia a quien enumera sus propios errores. La serenidad, cuando existe, no necesita anunciarse.

El AI en la sala

Hay, además, un debate técnico de fondo que sí merecía librarse y que casi nadie está librando por estar demasiado ocupado eligiendo bando: ¿qué significa fusionar un millón de líneas escritas por un modelo? La incomodidad de Kelley con las “contribuciones slop” no es del todo infundada como categoría —la pregunta por la revisión, la responsabilidad y la deuda técnica del código generado por IA es real y está sin resolver—. Pero es una pregunta que se responde examinando el proceso (la revisión adversarial con contextos separados, el fuzzing continuo, Miri en CI, la corrección de fugas instrumentables), no adjudicando quién tiene mejor gusto. La ironía es que el post de Bun ofrece material abundante para esa discusión, y la respuesta prefirió discutir a la persona.

Coda: elegir por mérito, no por bandera

Termino con una confesión de parte interesada. En mis proyectos uso el stack que, a mi juicio, cumple con la mayor parte de mis requerimientos técnicos y estratégicos, y en muchos casos ese stack ha resultado ser Rust. No lo digo para plantar otra bandera. Lo digo porque elegir herramientas por sus méritos —seguridad de memoria garantizada por el compilador, Drop en lugar de defer disciplinado a mano, un ecosistema que reduce cierta clase entera de bugs a errores de compilación— es justamente lo contrario del reflejo tribal que critico aquí.

Zig es un lenguaje excelente y Bun no existiría sin él; el propio Sumner lo repite. Rust le sirvió mejor a un problema concreto: mezclar memoria gestionada por un GC con memoria manual, un caso que casi ningún lenguaje diseña de forma explícita. Esa es toda la historia técnica, y es una historia sin villanos. Todo lo demás —la biografía, los rumores, la taza de té— es el ruido que ponemos cuando preferimos ganar la discusión a tenerla.