El soporte para Bun ahora será limitado y pasará a estar en desuso

• Este issue sigue en estado Open, y a partir del próximo lanzamiento de yt-dlp y/o de ejs, el alcance del soporte para Bun se limitará a versiones entre 1.2.11 y 1.3.14, y además ese soporte pasará a considerarse en proceso de desuso
• yt-dlp seguirá usando Bun como un runtime de JavaScript compatible con ejs, pero se reserva el derecho a eliminar por completo el soporte para Bun si la carga de mantenimiento aumenta demasiado
• La versión mínima soportada sube de 1.0.31 a 1.2.11; consideran que compilar el paquete ejs con Bun anterior a 1.2.0 ignora el archivo de bloqueo de ejs, lo que representa una seria preocupación de seguridad considerando los recientes ataques a la cadena de suministro de npm
• La razón para fijar 1.2.11 como límite inferior, y no 1.2.0, es que en versiones de Bun anteriores a 1.2.11 no se puede ejecutar la suite de pruebas de ejs
• El límite superior se fijó en 1.3.14, y se argumenta que esta fue la última versión construida sobre la base de código original en Zig
• Se plantea como preocupación futura de mantenimiento y confianza el hecho de que Bun fue reescrito recientemente en Rust usando Claude, y que su dirección de desarrollo parece orientarse a volverse “totalmente vibe-coded”
• Un comentario respondió que Deno también se está volviendo “vibe coded”, pero el mantenedor contestó que hay una gran diferencia entre usar Claude y depender completamente de Claude
• Ante la pregunta de si las versiones 1.3.4 a 1.3.14 también deberían excluirse del soporte por posible influencia del “vibe coding” tras la adquisición por parte de Anthropic, el mantenedor respondió que lo revisará
• Algunos usuarios se opusieron, señalando que bloquear la ejecución con las versiones más recientes de Bun antes de que exista un problema real es una restricción preventiva sin fundamento, y que debería permitirse continuar con advertencias o flags
• Otro comentario explicó que, como se puede pasar directamente la ruta del binario de Bun a --js-runtimes, es posible seguir usando la versión más reciente de Bun normalmente y asignar una versión estática de Bun 1.3.14 solo para yt-dlp como alternativa
• Junto con este aviso, también se enlazaron el issue sobre el fin del soporte para Node v20 y v21, y el issue para elevar la versión mínima soportada de Deno a v2.3.0; además, se indicó que la documentación wiki de EJS todavía no refleja este cambio
• El mantenedor dejó un comentario fijado, pensando en las respuestas llegadas desde Hacker News, pidiendo que antes de comentar consideren primero si realmente les interesa el problema de usar Bun en yt-dlp

[GN⁺]

Comentarios en Hacker News

• Se entiende la decisión. Si la mayor parte del código no fue escrita por quien le da mantenimiento, no debe ser nada fácil entender bien la base de código
  De hecho, revisar todo el código reescrito es prácticamente imposible. Son exactamente 1 millón de líneas de código https://github.com/oven-sh/bun/pull/30412

  • Que haya cambiado de Zig a Rust no significa que de pronto ya no se sepa qué contiene cierto archivo, cómo funciona o cómo se conecta con otros archivos
    Al final, es casi como escribir lo mismo con otra sintaxis, y por eso probablemente a los desarrolladores de Rust les parece feo. Da la impresión de que los desarrolladores de Bun querían código que les resultara familiar
    Aun así, creo que esto debió haberse llamado 2.0. Así habría parecido menos apresurado. Incluso en 1.3.14 ya hay algunas regresiones, pero ahora hay tantos pequeños incendios relacionados con Rust que parece que nadie les presta mucha atención
    El problema más grande es que Bun sigue persiguiendo funciones nuevas y brillantes y no termina de cerrar las cosas. Las pruebas cubren la mayor parte de Vitest, pero no todo; la mayor parte de Jest, pero no todo; y la mayor parte de pnpm, pero no todo. Ahora también metieron funciones de imagen, así que es la mayor parte de sharp, pero no todo. El servidor de desarrollo también es la mayor parte de Vite, pero otra vez no todo. Los procesos de larga duración son más o menos parecidos a Node, pero tienen fugas de memoria, y supongo que esa fue una motivación para el cambio a Rust
    Cuando vi la publicación sobre las rutinas de imágenes, se me bajó el ánimo. Era otro objeto brillante más, y junto con los bugs en las pruebas, al final terminé mudándome por completo a Vitest
  • Cuesta creer el argumento de que sí se pudieron escribir unos 2 millones de líneas de código Zig, pudiendo además seguir usando el mismo conjunto de pruebas incluido ahí, pero que no se puedan revisar 1 millón de líneas de código Rust
    No estoy convencido de que esta reescritura en sí sea una buena idea ni de que vaya a salir bien, pero la lógica contraria también me cuesta trabajo aceptarla
  • Esto es bastante común en culturas empresariales con alta rotación. Te asignan a un equipo que “da mantenimiento” a una base de código de millones de líneas con 10 años de antigüedad, y la persona con más tiempo en el equipo apenas lleva 1 o 2 años
    Nadie sabe qué hace ese más de 1 millón de líneas. A nadie le apasiona realmente trabajar con eso. Reciben requisitos y, salvo por la superficie que tienen que tocar, tratan todo lo demás como una caja negra
    Así terminas con 14 implementaciones de servicios de fondo que hacen lo mismo, 8 dependencias con el mismo propósito, 6 frameworks traslapados y una incompatibilidad total de estilos y enfoques. Y aun así, a nadie parece importarle mucho
  • Entre las bases de código bastante grandes que me toca llevar ahora hay algunas generadas con herramientas tipo agente cuyo funcionamiento la persona que las creó casi no entiende
    Me parece mejor que puro “vibe coding”, pero aunque eso podría ser tolerable en partes poco importantes, me cuesta aceptarlo en infraestructura central donde de verdad hay que pensar profundamente
  • También dan soporte a Windows, y en Windows actualmente hay millones de líneas de código que tampoco fueron escritas por quien hoy las mantiene

• No es como si estuvieran discriminando a alguien por su raza o religión. Si no quieres una gran superficie hecha con vibe coding, no veo por qué habría que dar tantas explicaciones
  Eso entra dentro de la discrecionalidad “artística” como desarrollador, y parece que la gente olvidó que el software, por naturaleza, lleva opinión incorporada

  • Viendo algunas publicaciones en GitHub Issues, parece que hay gente que siente que su religión fue atacada
  • Por los comentarios, parece que mucha gente asumió que el título se refería al propio Bun
  • Sí. Hacer un fork y subir solo el número de versión mínima no debería ser difícil. No lo he visto directamente, pero es muy probable que en algún lado solo haya que cambiar un número
    Si funciona, seguirá funcionando. Lo único es que ellos no quieren darle soporte ni mantenimiento ni resolver issues para eso
  • Se podría decir que se parece a discriminar por raza o religión, en el sentido de que se excluye con un criterio arbitrario y sin sentido
    Si Bun portado a Rust fuera mejor en todos los aspectos medibles, si pasara todas las pruebas, tuviera el mismo o mejor rendimiento y además corrigiera bugs existentes, entonces cuesta ver por qué importaría en qué lenguaje está escrito o cómo se implementó. Lo importante es que la calidad sea mayor
    Si no puedes confiar en la versión de Rust cuando el equipo de Bun la lanzó y aprobó, entonces tampoco es lógico confiar en la versión Zig de hace dos semanas. Los desarrolladores de yt-dlp quedan como tontos

• Me gusta muchísimo usar Bun, así que me da algo de tristeza ver que la dirección cambie de esta forma después de la adquisición por Anthropic
  Quiero un buen Node con baterías incluidas, pero no quiero que esté hecho con vibe coding

  • Me pregunto si realmente ya hubo problemas graves causados por esta conversión hecha con vibe coding
    No estoy diciendo que apoye la fusión. Estoy en contra de este enfoque YOLO de ingeniería. Solo que no he visto noticias desde el anuncio y tengo curiosidad por cómo va avanzando la transición
  • Según el equipo de Bun, ya llevaban varios meses haciendo vibe coding desde antes de la adquisición por Anthropic
  • En el momento de la adquisición, la gente esperaba que Bun siguiera más o menos como siempre, así que es irónico que al final esa expectativa haya quedado completamente destruida
    Claro, irónico en el sentido terriblemente triste
  • Si no se ha confirmado ningún problema concreto causado por el “vibe coding”, entonces reaccionar con rechazo automático sin verificar la evidencia real no deja de parecerse al comportamiento que se critica

• Esta decisión parece más un juicio político que uno de ingeniería. ¿Ya vieron aumentar en Bun los fallos de segmentación, la falta de memoria, las vulnerabilidades de seguridad o los bugs después de la reescritura en Rust?
  Claro que no, porque la reescritura todavía ni siquiera se integra. Parece más bien una decisión tomada porque la intervención de la IA da mala espina
  Las herramientas de ingeniería no se eligen por sensaciones, sino por si hacen lo que quieres que hagan. Si Bun empieza a tener más bugs y se siente como peor software, entonces dejaré de usarlo, pero ese juicio se basará en datos. Jarred ya hizo muchas cosas impresionantes con Bun, y no parece probable que publique una reescritura que no cumpla sus propios estándares de calidad, así que pienso observar qué pasa

  • Por otro lado, yt-dlp no tiene ninguna obligación de experimentar por su cuenta si el nuevo proceso de desarrollo de Bun termina aumentando los fallos de segmentación, los problemas de memoria o las vulnerabilidades de seguridad
    Si uno cree razonablemente que puede haber más vulnerabilidades, usar a los usuarios para experimentar sería incluso una irresponsabilidad
    La decisión responsable se parece más a “no vamos a dar soporte inmediato para ejecutar nuestro software en el nuevo lanzamiento de Bun cortado desde main”
    Lo que sí decepciona es que no parezca haber intención de reevaluar versiones futuras, sino más bien de no darle soporte nunca más. Aunque, claro, los desarrolladores de yt-dlp no le deben nada a nadie
  • No necesariamente es algo político. Puede que yt-dlp esté actuando políticamente, pero tener como principio no adoptar una dependencia crítica en producción hasta que lleve entre 6 meses y 1 año de uso generalizado normalmente no es política
    Una reescritura completa de 1 millón de líneas es, en la práctica, un runtime nuevo con el mismo ABI que el anterior, y para muchos consumidores aguas abajo resulta incómodo usar eso como dependencia de producción
    Incluso si, para efectos de la discusión, Bun se hubiera reescrito entero a mano por humanos, la situación sería la misma. Me parece una decisión bastante estándar y, aunque personalmente creo que la calidad general de la reescritura con LLM de Bun probablemente será buena, no apostaría mi producto ni mi empresa a ello. Prefiero elegir yo los cambios riesgosos en mi software, no asumirlos a la fuerza por una dependencia aguas abajo
  • Si esperas hasta que aumenten los fallos de segmentación, los problemas de memoria u otros errores, entonces ya fallaste en evitar el problema. Creo que esta dirección es la correcta, y la historia mostrará quién tenía razón
  • En los proyectos, la gobernanza es muy importante. Que los autores de Bun se hayan arrodillado ante los nuevos dueños muestra claramente dónde están sus prioridades
    No me voy a quedar sentado esperando a que empiecen a explotar bugs y todo se venga abajo
    Si un proyecto se guía por gente que piensa solo en “si la herramienta hace lo que quiero”, yo lo quitaría de mis dependencias
  • Uno de los elementos centrales de la ingeniería es predecir la trayectoria actual. En ese sentido, evitar herramientas que dan mala espina tiene todo el sentido del mundo
    El momento más fácil para alejarte de una herramienta que va camino a ser un choque de trenes es antes de integrarla

• Esto trata de la conversión a Rust, pero todavía no se ha lanzado
  Hablan de “problemas previsibles de compatibilidad y seguridad”, pero la versión Zig de Bun también se cae bastante
  Me gustaría que yt-dlp enlazara fundamentos más detallados de por qué habría problemas de compatibilidad previsibles. Ambos proyectos tienen suites de pruebas, así que en un mundo ideal una reescritura rápida debería ser posible
  Puede que no quieran avivar más la situación, pero si encontraron problemas concretos, me gustaría verlos
  Bun.rs debería haber sido una 1.4 o 2.0, y también me habría gustado que hubiera lanzamientos alfa/beta

  • Si de verdad algún proyecto hubiera mostrado datos de regresiones graves en Bun.rs, sería otra historia
    Pero apenas lleva una semana público y hasta ahora casi no se ven datos reales de regresiones. Se parece más a una queja de “simplemente no me gusta”

• Esta lógica se lee casi como “libfoo empezó a desarrollarse con emacs en vez de vim, así que ya no se puede confiar en él”
  Claro, no es exactamente lo mismo, pero se siente parecido por una razón
  La única verdad en software es si funciona en mi caso de uso. Incluso antes de la IA, no podías saber si quien lo escribió siguió un proceso riguroso o si simplemente probó cosas al azar hasta que parecieron funcionar
  Es decir, no juzgaba el software investigando la metodología o las herramientas usadas para hacerlo. He usado mucho software sin suite de pruebas o con pruebas desastrosas, y también hay gente que valora la seguridad de memoria pero usa herramientas escritas en C, y viceversa
  Por eso, la lógica de “no lo voy a usar porque no me gusta cómo usan la IA” me suena casi tan poco convincente como dejar de usar algo porque no te gusta qué editor usa su autor

  • Definitivamente hay personas a las que sí les preocupa cómo se hace algo y que toman decisiones según si están de acuerdo con ese proceso o no
    Si no fuera así, no existirían conceptos como el chocolate/café de comercio justo
  • Esa analogía ya se pasó demasiado. Ni siquiera está en el mismo estadio, ni en uno cercano
  • Entonces vayamos un paso más allá: imagina que programaron un trabajo cron para reescribir toda la base de código a un lenguaje nuevo cada primer lunes del mes. De Rust a C++, luego a Go, luego a Swift y luego de regreso
    ¿De verdad para los clientes que usan el producto eso sería casi lo mismo que el mantenedor cambiara de editor y un detalle irrelevante?
  • La mayoría pensaría que el editor de texto usado no influye de forma significativa en el código que se escribe
    Pero no mucha gente diría lo mismo de un LLM
    Vibe Bun podría ser tan bueno como el Bun anterior o mejor, pero ¿cómo podríamos saberlo ahora mismo?
    Y además, tampoco es cierto eso de que “no se podía saber si el software estaba hecho rigurosamente y no se juzgaba por metodología”. Hay gente que sí verifica por su cuenta si existe un nivel de rigor aceptable antes de adoptar un proyecto o decidir seguir usándolo. Yo también lo hago en cosas importantes
    Mucha más gente usa señales de reputación; no son perfectas, pero sí correlacionan y pueden bastar, además de ser mucho más fáciles que una revisión manual directa

• Hace muchísima falta un término nuevo para describir las formas de usar LLM en trabajo de desarrollo. “Vibe coding” tiene una definición estricta, pero parece que a nadie le importa
  Cuesta muchísimo creer que este port a Rust se haya hecho 100% por “vibra”, como en la definición original
  Todo esto se volvió un lodazal emocional, para bien o para mal, y usar “vibe coding” como un insulto genérico para cualquier uso de LLM hace demasiado difícil entender de qué problema real se está hablando
  Yo uso LLM para ayudarme a desarrollar, y estoy haciendo un mejor trabajo más rápido en todas las métricas que a un ingeniero le importarían

  • Vibe coding originalmente significaba “dejarse llevar por la vibra [...] y hasta olvidar que el código existe”
    https://x.com/karpathy/status/1886192184808149383
    En el caso de este port en particular, avanzó tan rápido que parece claro que una persona no validó la corrección de la traducción. Tampoco está claro si en el futuro realmente habrá validación manual
    Pero bajo el criterio de Dijkstra, la mayoría de los proyectos de software ya venían haciendo “vibe coding” desde mucho antes de la IA. Es decir, dejarse llevar y olvidarse de que la corrección existe
    Garantizar la corrección de código complejo es difícil, pero ahora que vivimos en la era de mil millones de hackers dentro del centro de datos, cada vez deja más de ser opcional
    Extra: “El port Rust previo al lanzamiento de Bun tiene 13,365 bloques unsafe”
    https://news.ycombinator.com/item?id=48239790
  • A diferencia de la afirmación de que usar LLM permite hacer mejor trabajo más rápido, los estudios sugieren que puede no ser más rápido e incluso podría ser más lento
    Es una tecnología tan nueva que cuesta estudiarla, pero incluso con una visión optimista, la evidencia empírica apenas muestra algo así como una mejora de alrededor de 3% en algunas áreas
    Es raro que escribir código sea el cuello de botella en nuestro trabajo

• No entiendo por qué tanta gente siente tanta presión con esta decisión. Si de verdad son fans del vibe coding, ¿no podrían simplemente hacer ellos mismos con vibe coding un yt-dlp mejor, o hacer fork del actual y adaptarlo como quieran?

  • He oído muchísimo que gracias al vibe coding hacer software ya es ridículamente fácil y que cualquiera puede hacerlo en un instante
    Incluso se decía que la gente iba a hacer con vibe coding software personal de un solo uso para todo
    Entonces, los vibe coders no deberían tener motivo para quejarse de ninguna decisión de software. ¿No debería ser facilísimo hacer con vibe coding un fork personal que les guste más? ¿No era esa la promesa del vibe coding?
  • Además, yt-dlp ya tiene soporte para plugins de intérprete de terceros. Ellos solo están diciendo que no quieren darle soporte directo a Bun, y la infraestructura para que otra persona use lo que quiera ya existe
    Esto es la clásica sensación equivocada de tener derecho sobre un proyecto mantenido con el tiempo y esfuerzo de otras personas. Sigue sorprendiéndome que haya gente que quiera convertir arbitrariamente en voluntario el tiempo y trabajo ajenos para obtener la función que quiere
    Quienes hacen el trabajo tienen derecho a tomar las decisiones, y si no te gusta, puedes hacer tu propio fork. Así ha funcionado siempre este ecosistema
    yt-dlp sigue siendo, de hecho, sorprendentemente fácil de tocar
  • Para muchos fans de la IA, aunque no todos, esto funciona casi como una religión. No les basta con que cada quien viva y deje que la historia muestre qué forma de construir software es mejor, sino que quieren que todo el mundo esté de acuerdo con ellos
    Vivo algo así en el trabajo, y de verdad desespera que con la IA parezca no permitirse un desacuerdo técnico honesto

• No sé bien cómo sentirme respecto a la reescritura de Bun
  Por un lado, da muchísimo miedo que la mayor parte de la base de código no haya sido revisada
  Por otro, por lo que he oído, pasa las pruebas casi sin regresiones
  Tal vez sea por falta de experiencia en ese tipo de cosas, pero yo no creo que confiara tanto en las pruebas como para depender por completo de ellas sin leer el código