Reescritura de Bun en Rust: "la base de código falla verificaciones básicas de Miri y permite UB en Rust seguro"

• Este issue está actualmente en estado Open, y la conversación fue bloqueada por desviarse del tema y limitada a colaboradores; además, se vincularon las correcciones relacionadas #30728 y #30876
• La persona que reportó el problema mostró que un valor creado con PathString::init puede seguir llamando a slice() incluso después de que el Box original haya sido dropped, por lo que Miri reporta Undefined Behavior basado en una dangling reference
• El código de reproducción consistía en pasar un búfer creado con Box::new(*b"Hello World") a PathString::init(&*test), y luego llamar a init.slice() después de drop(test); Miri arroja el error en core::slice::from_raw_parts
• robobun confirmó que el problema se reproduce y resumió que PathString::init es una función safe, pero aun así borra el slice lifetime, lo que permite crear un &[u8] colgante
• El #30728 vinculado apunta a convertir en unsafe fn los huecos paralelos de PathString::init y dir_iterator::next(), y a añadir comentarios SAFETY en unas 70 llamadas para dejar explícita la asignación de respaldo
• También se explica que esa misma corrección incluye un compile_fail doctest que obliga a requerir la palabra clave unsafe en tres firmas, además de una corrección a la fuga de fd por error de readdir en el resolver
• AwesomeQubic añadió además que PathString::init borra la provenance y que también falla con MIRIFLAGS=-Zmiri-strict-provenance
• JavaDerg explicó que init toma el lifetime implícito de &[u8], lo borra mediante una operación unsafe y devuelve un Self que parece 'static, permitiendo use-after-free e invalid aliasing
• JavaDerg advirtió que, dentro del modelo de seguridad de Rust, el UB puede causar problemas en lugares inesperados; por ello hace falta revisar el uso generalizado de unsafe, y no es adecuado traducir 1:1 a Rust las estrategias de manejo de memoria de otros lenguajes
• robobun añadió como commits relacionados las pruebas de PathString::init signature stays unsafe y dir_iterator: make next() unsafe; audit call sites
• SimonReiff señaló que el resultado de hacer grep de unsafe en los archivos Rust del repositorio, excluyendo comentarios, es de 13255 líneas, y exigió revertirlo de inmediato y discutir la política y los procedimientos sobre el uso de código generado por IA
• Jarred-Sumner indicó que el port actual a Rust tomó como punto de partida un mapeo 1:1 lo más cercano posible al código original en Zig, y que sigue mejorándose; además pidió que se sigan reportando en nuevos issues los bugs o comportamientos no sólidos del código Rust

[GN⁺]

Comentarios en Hacker News

• Lo que primero me interesó de Bun fue que estaba escrito en Zig, y lo que me atrajo de Zig fue que confiaba en las decisiones y el criterio de Andrew Kelley
  Después, las razones por las que Bun me fue interesando más también terminaron siendo elecciones que me parecían respetables, y hasta después de la adquisición por Anthropic intenté mantener un optimismo cauteloso
  Pero este movimiento parece una decisión en la que cuesta confiar; no es que Rust sea el problema, sino que si Anthropic va a manejar Bun de esta manera, ya no se siente como algo por lo que pueda apostar como componente confiable de mi caja de herramientas
  No solo hay que confiar en el código, sino también en la forma de pensar que hay detrás, y ahora parece más una herramienta de uso interno de Anthropic

  • Bun es un proyecto realmente interesante, pero la cantidad de segmentation faults que aparecían en los issues me preocupaba demasiado como para usarlo en un entorno serio de producción
    Esta dirección podría ser una forma de corregir eso, así que habrá que ver
  • Lo entiendo, pero mi punto de partida es bastante distinto
    Como viejo fan de Deno, Bun me parecía una versión menos ambiciosa de Deno, y como no quería aprender Zig, era poco probable que me pusiera a tocar Bun por hobby
    Pero en los últimos años, tratando de mantener una base de código TypeScript bastante grande de una forma menos atada al runtime, me fui abriendo cada vez más a Bun, y aunque no quería hacer de un runtime específico de TypeScript un requisito, Bun seguía dando razones como Postgres, SQLite, S3, websockets, almacenamiento local de secretos, bundling, compilación y velocidad
    Ahora estoy convirtiendo varios servidores API y servidores de apps frontend en un único ejecutable con bun build --compile --bytecode para ejecutarlo e implementarlo casi en cualquier lugar
    Aun así, no creo que esta forma de trabajar sea común, y si este port basado en LLM falla, estoy en una posición perfecta para arrepentirme de todas mis decisiones relacionadas con Bun
    Pero si no falla, es interesante. Sería un caso que muestra lo que se puede hacer con LLM, y que Bun se desarrolle en Rust a futuro me parece una ventaja
    Y si falla, igual es información importante. Bun es uno de los runtimes principales de TS/JS, y Anthropic tiene recursos enormes, acceso a los modelos más recientes y un presupuesto prácticamente ilimitado, así que si ellos no pueden hacerlo, casi significa que de verdad todavía es imposible
  • Me da curiosidad por qué Bun te atrajo más que Deno

• Si iban a mover Zig a Rust inseguro, no entiendo por qué no hicieron una herramienta de traducción
  Podrían haber obtenido una conversión determinista mapeando las estructuras del lenguaje uno a uno y hardcodeando los patrones de la base de código; como dijo un amigo, hasta habría sido posible algo como “conectar zig translate-c a c2rust”
  El resultado actual es incluso menos confiable que la entrada. La entrada no era memory-safe, pero era código escrito por humanos; la salida no solo no es memory-safe, sino que además fue hecha con vibe coding y ni siquiera parece que un humano la haya revisado bien
  No entiendo cuál es el sentido de abusar de una IA agéntica para este uso

  • Si alguna vez viste el resultado de c2rust, es difícil decir eso
    Termina imitando la semántica insegura de punteros de C con una biblioteca de funciones inseguras en Rust, así que el resultado es terrible
    Hace algunos años, mientras revisaba un bug de OpenJPEG, alguien intentó convertirlo con c2rust, y el Rust inseguro resultante daba segmentation fault exactamente en el mismo punto que el código en C
    Es compatible, pero no seguro
    La clave es no hacer manipulación de strings en C o en Rust inseguro. Es una herramienta totalmente inadecuada para ese trabajo
  • Sí la hicieron. Una herramienta de traducción muy dinámica
  • Eso de “conectar zig translate-c a c2rust” no funciona tan bien como parece
    Estas herramientas tienen muchos errores y generan código muy verboso y difícil de razonar
    Puede servir para apps pequeñas, pero no para una reescritura completa
  • Yo dije casi lo mismo en otro hilo, pero tengo una visión un poco distinta sobre cómo escribir software
    Más que traducir Zig a Rust, me parece mejor escribir un parser JPEG en Python estático y luego bajarlo a Zig y Rust con estructuras idiomáticas para cada lenguaje
    Para eso hice un parser de un dialecto de Python pensado para este propósito, y quiero adoptar algunas capacidades de Rust/Zig que faciliten la traducción manteniendo compatibilidad con la mayor parte del código Python
    El parser JPEG también está incluido como ejemplo
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • La forma correcta de portar una base de código a otro lenguaje es parsear el árbol sintáctico y aplicar transformaciones deterministas y verificadas

• Este issue lleva a confusión
  El problema no es la mera existencia de undefined behavior que miri puede detectar, sino haber expuesto una API que puede provocar undefined behavior desde código seguro. miri también solo lo detecta si escribes un test que lo demuestre
  Que esto pase durante un port inicial desde un lenguaje inseguro no es del todo irracional
  El equipo de Bun también parece estar revisando después si las funciones que envuelven código inseguro son correctas
  Marcar temporalmente algunas funciones inseguras como seguras durante la etapa de port no es en sí un gran problema, pero sí es un poco raro haberlas fusionado así al repositorio principal
  El problema real sería liberar código en ese estado
  Lo lamentable es que no configuraron desde el inicio la ejecución de tests con miri, porque los LLM responden bien a buenos tests
  No lo digo por este issue de GitHub, sino porque otro test [1] sí invoca en la práctica undefined behavior que miri detectaría. Aun así, el código bajo prueba no parece usarse en ninguna parte, así que el impacto real no parece grande
  Como esto es el inicio del port, quizá luego lo arreglen, e incluso pueden eliminar código inseguro que en realidad no hace falta
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - los punteros derivados de la primera referencia mutable quedan invalidados cuando se crean nuevas referencias mutables al mismo objeto. En términos de C, se puede pensar en una “referencia mutable” como una “referencia restrict sobre la que se hace una modificación trivial”
  Para hacerlo bien, todos los punteros deberían derivarse de la misma referencia mutable, pero simplemente no lo hicieron así
  Si van en masa a GitHub a inundarlo, solo van a hacer menos probable que la gente trabaje en público. Ojalá no lo hagan
  Y convendría reservar el juicio hasta que esté en un estado publicable. Evaluar trabajo intermedio no es justo ni muy interesante

  • Cuando un proyecto ya llegó a 1.0, mucha gente espera que la rama main siempre funcione
    Porque CI/CD casi parte de la premisa de que todos los commits deberían funcionar
    Código en progreso que no funciona, como una reescritura completa, debería ir en una rama
    Así también puedes mantener un main funcional cuando haga falta, por ejemplo, una corrección de seguridad

• Este resultado no sorprende porque lo que se pidió fue casi un port literal
  Tal vez tenga sentido mover primero Bun a un lenguaje con un sistema de tipos más fuerte y luego usar ese sistema como base para mejoras posteriores
  Parece mejor que exigir perfección desde la primera etapa

  • En realidad eso es lo que están haciendo
    Están resolviendo los issues que van entrando
  • Bastaría con agregar al prompt “hazlo sin undefined behavior”
  • Ahora parece que incluso se puede presionar la reescritura con herramientas como miri para que Claude Code la mejore automáticamente
  • Que aparezca undefined behavior en código Rust mayormente traducido de forma literal y en parte inseguro no sorprende
    Lo decepcionante es que la API del código Rust pueda provocar undefined behavior sin estar marcada como unsafe
    Si yo hiciera una traducción así, sería conservador y al principio marcaría todo o casi todo como unsafe
    Luego ya se puede verificar gradualmente la seguridad de cada parte

• Sinceramente, me sorprendió un poco que dijeran que quedó totalmente funcional en solo una semana
  Mi proyecto paralelo https://tsz.dev tiene una ambición parecida, pero no puedo decir que haya tenido éxito
  Sigo agregando tests para comprobar el comportamiento, y aun después de pasar todos los tests del propio TypeScript sigo encontrando bugs, como era de esperarse
  El estándar de igualar el comportamiento de tsc es realmente altísimo
  https://github.com/type-challenges/type-challenges
  No estoy en contra de escribir mucho código con LLM, pero ahora que se puede producir código a esta velocidad, la validación tiene que ser 100 veces más sólida

  • Lo impactante es que hayan fusionado en una semana, como “experimento”, una base de código de un millón de líneas que muy probablemente casi no fue revisada
    No estoy en contra de usar agentes, pero apresurar algo así y sorprender de golpe a la comunidad se ve muy amateur
    Es el tipo de comportamiento que uno esperaría de un ingeniero junior demasiado entusiasta
  • https://tsz.dev/sound-mode/
    Esto es excelente. TypeScript necesita más cosas así, y ojalá se conozca más para que Microsoft incluso lo adopte
    Eso sí, habría que tener cuidado con llamarlo sound mode
    La frase “no es una prueba de soundness en el sentido matemático, y no hace verdaderos los archivos .d.ts de terceros” mezcla dos cosas completamente distintas
    Primero, la soundness es un concepto matemático. Si algo es sound, realmente lo es, y significa que puedes confiar en el compilador sin tener que revisar los detalles manualmente
    Si hay bugs de implementación, puede fallar, pero eso se puede corregir; la soundness significa que no hay fallas teóricas en la especificación o en el sistema de tipos mismo
    Segundo, es totalmente razonable y esperable que un lenguaje real necesite capacidades no verificadas en las que se confía en que la gente use correctamente. Como unsafeCoerce en Haskell o sun.misc.unsafe en Java
    El problema real es cuando el sistema de tipos se rompe incluso sin usar esas capacidades
  • Decir que funciona es un poco exagerado
    Solo miré el código unos minutos, pero parece que se va a romper fuerte apenas actives optimizaciones
  • Probablemente llevaban meses planeando y experimentando con esto
    Además del gran test suite existente, debían tener herramientas para paralelizar agentes y un presupuesto de tokens prácticamente ilimitado, así que tampoco hay que desanimarse demasiado

• Hay un libro [0] que me cambió mucho la manera de pensar sobre la atención y los medios
  El libro en sí no es tan bueno, pero sí señala algo relevante aquí
  Hay una enorme asimetría entre el alcance de un anuncio grande y llamativo, por ejemplo “Bun fue reescrito en Rust memory-safe en unas pocas semanas”, y el alcance de la corrección, por ejemplo una nota al pie en un artículo viejo o un issue de GitHub
  Esta asimetría es algo que la industria del marketing y PR entiende muy bien y explota activamente
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Viendo el ambiente de ahora, parece que hay mucha gente buscando cualquier crítica al código para amplificarla al máximo
    Por ahora, la mayoría se ve bastante superficial
    Fusionar un port grande asistido por LLM fue sin duda una decisión muy audaz, pero no veo mucho de lo que la gente señala sobre el resultado real que me parezca peor que otros ports en progreso
    Cada issue que aparece se está inflando de más
  • Para empezar, ni siquiera sé si de verdad afirmaron que era memory-safe
    En todas las discusiones sobre este tema aparecieron decenas de comentarios diciendo que la base de código hecha con vibe coding iba a explotar por bloques unsafe no auditados, y que parecía haber gente revisándola por encima sin entender Rust
    Incluso a veces parecía que se enojaban con la mera idea de que haya que entender cualquier lenguaje de programación
  • Me hace pensar en esa cita de que “una mentira da la vuelta al mundo antes de que la verdad siquiera se ponga los zapatos”
  • No solo marketing y PR; también los medios tradicionales saben que si primero publican tonterías y luego se retractan, el efecto persiste
    La gente suele recordar el artículo o titular original, pero no llega a ver la corrección
  • En realidad pensé que ibas a hablar del problema en la dirección contraria
    El port todavía está en curso, así que no hubo ningún gran anuncio llamativo, y todavía no está terminado ni liberado
    Lo que sí veo como anuncio llamativo son las burlas oportunistas sobre código en progreso, y los intentos de insinuar que el equipo dijo que ya estaba terminado o perfecto
    La reescritura era una traducción de código para usarla como punto de partida
    El equipo de Bun nunca anunció a lo grande que el código ahora fuera memory-safe, y siempre dejó claro que era un punto de partida
    O sea, esperar que fuera perfecto de inmediato y que resolviera todos los problemas de memoria del código original en Zig es pelear con un anuncio imaginario, no con lo que el equipo de Bun realmente dijo
    También me pregunto si alguien ha intentado mapear si este problema de memoria ya existía en la base de código original

• Este tipo de errores era previsible
  Para la gente que necesita estabilidad, dejaron la versión estable en Zig, y supongo que con el tiempo esos errores se van a corregir

  • Estos errores sí eran bastante evitables
    El ecosistema Rust tiene herramientas bien conocidas para detectar este tipo de errores, y aunque no atrapen todo el undefined behavior causado por equivocaciones en bloques unsafe, ejecutarlas se considera una buena práctica

• Lo que más me preocupa es la metaconversación
  Al principio vi de forma crítica a los mantenedores que cerraron este issue de GitHub por considerarlo fuera de tema
  Pero la interfaz de GitHub estaba auto-plegando en masa mensajes sin ningún valor informativo, y esos mensajes parecían venir en oleadas desde foros o el Discord de la comunidad
  Esto pone a todos en una situación perdedora
  Alguien que encuentra un problema importante que preocuparía a buena parte de una comunidad tiene razones de sobra para difundirlo lo más ampliamente posible
  Es un pedido sustancial sobre cambios recientes, y cuestionar el tono no hace desaparecer la veracidad
  El problema es que la atención extra literalmente mató la discusión
  Del lado de los mantenedores, eso también puede servir de escudo para quien tome decisiones más emocionales o cercanas a una psicosis por IA
  Un proyecto con mentalidad de asedio que bloquea e ignora las críticas puede descarrilar muy rápido
  Por otro lado, en un proyecto que no protege a sus mantenedores de la ansiedad y las patologías alrededor de la IA, el burnout de los mantenedores es inevitable

• Esta reescritura de Bun se siente como un posible evento pensado para el marketing de Mythos

  • Hasta ahora, ni el equipo de Bun ni nadie de Anthropic lo ha promocionado exagerándolo más allá de decir que se está cambiando a un lenguaje más memory-safe y con mejores garantías del compilador
    El ruido y la publicidad hasta ahora vinieron sobre todo de la reacción negativa de gente contraria a la IA
    En mi opinión, también se mezcla mucho con una percepción negativa creciente sobre la propia Anthropic por algunas de sus decisiones recientes
  • Simplemente parece un rug pull corporativo
    Da la impresión de que las necesidades de Anthropic son la única prioridad y que todo lo demás no les importa
  • Ejecutan la reescritura gastando quién sabe cuánto dinero en tokens ilimitados
    Luego hacen mucho ruido y escriben un post de blog diciendo “Claude Code permitió al equipo de Bun reescribir más de un millón de líneas de Zig a Rust”, y los VC se relamen
    Falla en chequeos básicos
    Dejan que Mythos haga pedazos la base de código y quién sabe cuánto más gastan
    Escriben otro post aparte
    Estafadores y gente ingenua aplauden y lo defienden contra la “multitud delirante anti-IA”
    Los VC se emocionan todavía más
    Así es como se gana dinero
    Y de ahí se pasa a que ahora también hay que deshacerse de los ingenieros de software

• Si ya hay una base de código en un lenguaje inseguro y además bindings a otro lenguaje inseguro, no sé por qué alguien asumiría que iba a verse perfectamente implementado de inmediato