Bun (runtime de JS) está siendo porteado vibe-coding de Zig a Rust

 (github.com/oven-sh)
1 puntos por GN⁺ 2 시간 전 | 2 comentarios | Compartir por WhatsApp
  • Jarred Sumner, fundador de Bun, hizo commit de una guía de portabilidad Zig → Rust (PORTING.md) en la rama claude/phase-a-port, dejando al descubierto un experimento de conversión masiva de lenguaje con agentes de IA
  • La portabilidad se divide en Phase A (traducción preliminar solo de la lógica por archivo, sin necesidad de compilar) y Phase B (lograr que compile por crate), usando un método en el que se le entregan al LLM unas 300 reglas de mapeo de tipos e idioms
  • El propio Sumner aclaró en Hacker News que "no han decidido reescribirlo y es muy probable que todo este código termine desechándose", así que por ahora está en una etapa experimental de exploración
  • En la comunidad se menciona como contexto el choque con la política de Zig que prohíbe contribuciones de IA tras la adquisición por parte de Anthropic, el hecho de que Bun ya opera con un fork de Zig, y las ventajas de seguridad del ecosistema de Rust
  • La mayoría de los PR se generan automáticamente por @robobun (bot de IA) y luego los revisan CodeRabbitAI y Claude, mostrando un caso real de las posibilidades y límites de una migración de código a gran escala guiada por IA

Estructura clave de la guía de portabilidad (PORTING.md)

  • El objetivo es convertir un archivo Zig a un archivo .rs dentro del mismo directorio; en Phase A la meta es la reproducción fiel de la lógica y no importa si compila o no
  • Se prohíbe usar crates externos de asincronía e I/O como tokio, rayon, hyper, async-trait, std::fs, std::net, porque Bun controla su propio event loop y syscalls
  • Se prohíbe async fn; todo el procesamiento asíncrono debe mantenerse igual que en Zig, con el esquema de callbacks + máquina de estados
  • Lo que no se pueda determinar con certeza se marca con // TODO(port):, y los idioms de Zig relacionados con rendimiento con // PERF(port):, para resolverlos en Phase B

Reglas de mapeo de tipos e idioms

  • Se proporciona una tabla con más de 50 mapeos de tipos, como []const u8 → &[u8] (nunca &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
  • defer x.deinit() → eliminar y sustituir por impl Drop, errdefer → usar scopeguard, comptime → convertir a const generics, const fn o macro_rules!
  • El principio para strings es el manejo basado en bytes: se prohíbe usar std::string::String o &str y se deben usar &[u8]/Vec<u8>, porque Bun maneja WTF-8 y bytes arbitrarios
  • Se ordena la correspondencia de funciones integradas de Zig con equivalentes en Rust, como @intCast → T::try_from(x).unwrap() (siempre con verificación), @truncate → x as T (wrapping intencional), @bitCast → transmute

Mapa de crates y modelo de ownership

  • Los namespaces de Zig como @import("bun").X se mapean 1:1 a unas 30 crates de Rust como bun_str, bun_sys, bun_jsc, bun_alloc
  • Las crates de AST/parser conservan la arena bumpalo::Bump, mientras que las demás usan un asignador global mimalloc, eliminando así los parámetros de allocator
  • Mapeo de ownership de punteros: bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>

Reacción de la comunidad (Lobsters · HN)

  • Hay muchas opiniones que cuestionan si realmente quieren migrar a Rust o si esto es un showcase del LLM de Anthropic
  • Se especula que el trasfondo podría ser el choque entre la política de Zig que prohíbe contribuciones de IA y el workflow de desarrollo centrado en IA de Anthropic, aunque también se reconoce que esto roza la conspiración
  • Hay escepticismo sobre si un LLM puede seguir fielmente unas 300 reglas, aunque también aparecen valoraciones positivas como "~16k tokens es una cantidad razonable para un subagente"
  • Una observación interesante es que el enfoque de crear primero código que no compila en Phase A va en dirección opuesta al uso habitual de agentes de coding
  • También se menciona como posible motivación la carga de mantener el fork de Zig de Bun, los frecuentes breaking changes de Zig y el riesgo de depender para un producto clave de un lenguaje que todavía está en beta

Lecturas relacionadas

2 comentarios

 
GN⁺ 1 시간 전
Comentarios en Hacker News

  • Trabajo en Bun y esta es mi rama.
    Este hilo en general es una sobrerreacción. Hay 302 comentarios sobre código que ni siquiera funciona, pero todavía no se ha decidido reescribirlo y también es muy probable que todo este código termine descartándose.
    Quiero ver cómo se ve una versión que sí funcione, qué sensaciones da, cómo rinde, y qué tan difícil es lograr que pase la batería de pruebas de Bun y que además sea mantenible. Me gustaría comparar lado a lado una versión viable en Rust y otra en Zig.

    • Es una lástima que algunas personas reaccionen con tanto entusiasmo porque se subió un commit experimental a una rama experimental. Si dejamos un momento las emociones de lado y lo miramos por sus méritos, probablemente muchos también estarían de acuerdo con la motivación para estudiar un enfoque así.
      La parte de “qué tan difícil es hacer que pase la batería de pruebas de Bun y que sea mantenible” resulta interesante en una época en la que cada mes aparecen nuevas oportunidades de abstraer por completo el proceso de portar código con agentes, y todo esto además está basado en lingüística.
      Si buscan un caso parecido e igual de interesante, hace unos meses Cloudflare mostró vinext, que porta Next.js. Al principio tuvo problemas de adaptación, pero ahora ya se usa en algunos proyectos de producción sin grandes inconvenientes.
      [0] - https://github.com/cloudflare/vinext
    • Me gusta el trabajo de Bun, pero me pregunto cómo ven que últimamente sigan apareciendo preocupaciones sobre la calidad del proyecto. Parte de eso puede ser el típico odio estilo Twitter, pero también hay problemas reales.
      Parece razonable que la gente pregunte por qué se agregan procesamiento de imágenes o webviews dentro de un runtime de JavaScript mientras siguen sin atenderse bugs que afectan producción. Por ejemplo, uno de nuestros mayores bloqueadores es https://github.com/oven-sh/bun/issues/6608, reportado en 2023, y tres años después todavía nos sigue afectando.
    • Me pregunto cuál es la motivación principal para evaluar Rust.
      Como referencia, la última vez que usé Bun me encontré con algunos bugs en partes como Bun.write donde Rust probablemente habría ayudado.
      [0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
    • Es una pena ver una reacción tan fuerte ante una investigación legítima. Para algunas personas, Bun se percibe como el proyecto insignia de Zig, especialmente entre quienes están molestos con Rust y por alguna razón quieren que Zig “le gane” a Rust.
      Al final, sin importar el lenguaje o la herramienta, lo correcto es elegir lo que mejor encaje con el proyecto y la situación. En lo personal, este experimento me parece interesante y tengo curiosidad por ver cómo evoluciona. Como escribir Rust idiomático requiere un cambio de mentalidad, también vale la pena ver qué tan bien se adapta un LLM a eso con el tiempo.
    • Tengo una curiosidad tranquila por el resultado.
      Ojalá el código termine siendo elegante, no solo mantenible sino también preparado para el futuro y con buen rendimiento.

  • Me parece interesante ver esto justo cuando el post principal actual en HN trata sobre la preocupación por Bun a raíz de la adquisición de Bun por parte de Anthropic. El comentario más votado allá tenía un tono tipo: “Anthropic hará experimentos en su propia base de código, no van a poner al equipo de Bun a hacer ese tipo de experimentos de vibe coding”.
    Pero lo que se ve ahora parece justamente trabajo a gran escala hecho con vibe coding.
    El tiempo dirá cómo termina, pero estaría bien que los mantenedores de Bun explicaran qué están haciendo aquí y por qué.

    • Hace poco intentaron upstreamear mejoras a Zig, pero se toparon con la estricta política de prohibición de código generado por IA que tiene Zig. Cada quien decidirá si esta reacción busca meter presión sobre Zig o si se están moviendo por razones prácticas.
      Probablemente sea un poco de ambas.
    • Puede que esto no sea un trabajo tan grande como parece. En las últimas semanas estuve experimentando con IA para reescribir Postgres en Rust, y la IA resultó bastante buena para este tipo de trabajo de reescritura.
      Tener una base de código existente como referencia elimina muchos de los problemas típicos del vibe coding. Ya hay una arquitectura funcional y una batería de pruebas contra la cual comparar.
      En un mes pasé de no tener nada a superar más del 95% de la batería de pruebas de Postgres. Si Jarred fue quien creó Bun, imagino que podría avanzar mucho más rápido.
      [0] https://github.com/malisper/pgrust
    • No sé si haya personas en común entre estos equipos, pero Anthropic en sí parece estar invirtiendo bastante en el ecosistema de Rust.
      Hace poco propusieron parte de sus herramientas internas como implementación oficial en Rust de Connect RPC. Incluye un conjunto de bibliotecas basadas en Protobuf y también Buffa, un nuevo compilador de Protobuf basado en Rust.
      [0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...
      [1]: https://connectrpc.com/
      [2]: https://github.com/anthropics/buffa
    • Claude probablemente maneje mejor Rust que Zig.
    • No veo por qué tendrían que explicarlo. Esto solo parece trabajo base para un refactor inicial y una posible migración de lenguaje; todavía no se ha confirmado que realmente vayan a cambiar de Zig a Rust.
      Si eres inversionista y quieres ver si están usando bien su tiempo, lo entiendo, pero fuera de eso no veo por qué debería importarles tanto a los demás.

  • Es interesante cómo cambian los tiempos. En 2015, todo el runtime de Go, que ya era una base de código madura, fue reescrito de forma semiautomática de C a Go. Uno de los mantenedores creó una herramienta de conversión de C a Go orientada al subconjunto de C que usaban, para que compilara y produjera la misma salida; luego el código resultante fue retocado por personas para hacerlo más idiomático y optimizado en Go.
    Ahora simplemente se le puede pedir eso a un modelo de lenguaje.
    Diapositivas:
    https://go.dev/talks/2015/gogo.slide#3
    También hay un paralelismo interesante.

    We had our own C compiler just to compile the runtime.
    El equipo de Bun también mantiene su propio fork de Zig.

    • La gran diferencia aquí es que la herramienta de C a Go probablemente era determinista. Si la corrías varias veces, seguramente daba exactamente el mismo resultado.
      Como una persona escribió, entendió, probó y depuró esa herramienta de conversión, se podía confiar en su resultado.
      Un LLM no es determinista. Si le pides la conversión 10 veces de forma independiente, obtendrás 10 resultados distintos, y algunos pueden diferir bastante. No hay forma de validarlo sin revisar todo a fondo cada vez.
      Eso no significa que una herramienta de conversión determinista hecha por humanos sea perfecta o esté libre de errores, pero sí permite construir mucha más confianza que un LLM.

  • El commit enlazado no parece respaldar mucho el título. Hay una rama donde Claude está reescribiendo en masa código de Zig a Rust, y por ahora va en 773,950 líneas agregadas y 151 eliminadas.
    [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

    • Es impactante. Cuando Jarred recién dejó Stripe, también dejó varios PR de más de 10 mil líneas reescribiendo código del dashboard, y tardaron meses en procesarlos. Una diferencia de 750 mil líneas es, en la práctica, imposible de revisar.

    • Me dio curiosidad el tamaño de este trabajo, así que saqué el top 5 según cloc.

      Language files blank comment code

      Zig 1298 79693 60320 571814
      TypeScript 2600 67434 115281 471122
      JavaScript 4344 36947 37653 290873
      C++ 583 27129 19117 215531
      C 111 21577 83914 199576

  • Una forma más lenta, pero con posibilidades de éxito, sería seguir el historial de commits de git como si fueran niveles de un candado, aplicando la intención funcional de cada commit.
    Así también me gustaría saber si la implementación en Rust pudo saltarse ciertos commits de corrección de bugs simplemente porque evitó el problema de origen.

    • Es una idea interesante y quizá valga la pena probarla en un proyecto más pequeño. Bun tiene más de 15 mil commits, así que para terminar sin hacer decenas de miles de llamadas a la API habría que encontrar una forma de procesar grupos de commits en un solo prompt.
    • En el issue tracker de Bun hay muchos segmentation faults. Si se pasan a Rust, probablemente evitarían bastantes de ellos.

  • Considerando que hace poco Bun/Anthropic se quejó de los tiempos de compilación de Zig, es decir, que no aceptaron un PR con mejora de 4x en velocidad de compilación hecho con vibe coding, resulta una movida “interesante” querer migrar a un lenguaje que probablemente compile unas 4 veces más lento que Zig base.

    • Soy muy escéptico con la idea de que Zig realmente compile más rápido que Rust.
      He escrito código parecido en Zig y en C++, y la compilación en frío fue varias veces más rápida en C++, mientras que la compilación incremental en C++ terminaba casi al instante.
      Creo que la razón principal por la que los proyectos Rust compilan lento es el abuso de dependencias y el uso excesivo de metaprogramación en el código.
      Zig no tiene múltiples unidades de compilación, así que no puede paralelizar la compilación.

  • Tengo muchísima curiosidad por cómo va a terminar esta migración con IA. Participo en varios proyectos activos donde el lenguaje o framework está frenando al proyecto, pero son demasiado grandes como para reescribirlos solo con esfuerzo humano.
    Me ha ido mejor con vibe coding en Rust que en lenguajes dinámicos. Da la impresión de que la rigurosidad del compilador de Rust obliga al agente de IA a producir mejor código. No estoy seguro; también puede ser que, como conozco menos Rust, me parezca que lo hace mejor.

    • Rust es una buena opción para dejar correr un LLM sin demasiada supervisión. En mi experiencia, sí hay que vigilar muy de cerca el avance, y una persona debe conservar la propiedad del diseño de lo que se está creando o portando.
      Un test harness es indispensable. Hay que correr pruebas en cada iteración para confirmar que no rompió otra cosa.
      Ahora mismo estoy portando TypeScript a Rust, y en el proceso he aprendido bastante. El trabajo en curso se puede ver aquí https://github.com/mohsen1/tsz/
      Puedo compartir lo que he aprendido.
    • Para algunos trabajos estoy eligiendo Go en vez de Rust. Aun así, de forma parecida, aunque no soy programador de Go, parece funcionar suficientemente bien. Pero tampoco lo estoy abordando desde una ingenuidad total, porque llevo décadas trabajando con bases de código muy distintas.
      La forma de compensar mi incapacidad para revisar el código al detalle es asegurarme de que las pruebas, pruebas de integración y pruebas end-to-end cubran todo lo que me importa. Sin eso, no puedes estar seguro de que no se saltó trabajo fino.
      También le hice correr benchmarks y pruebas de estrés, y analizar la base de código para encontrar posibles cuellos de botella. Detectó y corrigió algunos problemas, y luego mejoró. Por último, si le pides revisión crítica, oportunidades de refactor y cosas así, arma bastante bien una lista de qué corregir después.
      Hacer que ejecute detectores de fugas de memoria y herramientas de análisis estático también es una buena estrategia. Si con ese enfoque ya quedan menos cosas por encontrar, entonces probablemente el código no sea espantoso. Al menos habrá llegado a algún óptimo local.
      Que no haya revisión de código suena bastante terrible, pero en codificación asistida por IA se está volviendo rápidamente el mayor cuello de botella. Quitar ese cuello da miedo, pero multiplica por varios órdenes de magnitud la cantidad de código posible. Un compilador estricto y una gestión estricta de memoria ayudan a eliminar algunas categorías de bugs.
      Antes hacía este trabajo en lenguajes que sí entendía. Cuando empiezas a manejar commits más grandes de forma cotidiana, la revisión se vuelve un problema.
      Creo que este tipo de trabajo sobre bases de código grandes será mucho más fácil y mucho mejor con el tiempo. El principal dolor de cabeza de este tipo de ingeniería es la tendencia del modelo a tomar atajos deliberadamente, probar solo el camino feliz y dejar el trabajo duro para después.
      Muchos modelos parecen sesgados a ahorrar uso de tokens. Es bastante molesto, pero se compensa fácil con prompts de seguimiento y pruebas, y será un problema menor si ajustan mejor los modelos para que se comporten bien incluso sin prompts adicionales.
    • Eso es el efecto Dunning-Kruger. Pero al menos lo reconoció.
    • Sí, genera código Rust bastante basura.
      Eso de “también puede ser que, como conozco menos Rust, me parezca que lo hace mejor” suena bastante posible.

  • Espero que Zig tenga éxito, pero todavía no es 1.x, así que una base de código tan grande como Bun probablemente tendría dificultades para manejar cambios incompatibles importantes.
    Además, Bun usa un fork de Zig https://x.com/bunjavascript/status/2048427636414923250?s=20

  • No entiendo por qué no reescriben claude-code en Rust.
    Anthropic adquirió al equipo de Bun porque claude-code usa Bun, y ahora parece que quieren portar Bun de Zig a Rust porque Rust “es mejor”. En otras palabras, se supone que quieren hacer claude-code “mejor”, así que no entiendo por qué tomar un camino tan complicado.
    Con la capacidad de LLM que ya tienen, podrían simplemente escribir claude-code directamente en Rust y dejarlo en su mejor estado.

    • Seguro no se tragaron su marketing “de base” tan descarado, y como sabría cualquier gran ingeniero, los LLM no son la herramienta adecuada para este trabajo.
      Bun también es fácil de ver como un truco de marketing.
    • Hasta donde sé, claude code es React renderizado como UI de terminal. Parece que de verdad quieren usar React. Supongo que eso es lo que le pasa al cerebro cuando haces demasiada IA.

  • Hasta ahora, gran parte de lo sorprendente de claude/codex ha estado atado a aplicaciones construidas dentro de los límites y casos extremos de bibliotecas ya existentes. El modelo aprovecha directamente excelentes trabajos humanos como Python, requests y ffmpeg.
    Pero espero con interés la etapa en la que el monstruo se salga de esas restricciones: reescribiendo, parchando, renombrando y reconstruyendo bibliotecas, DLL y binarios. Cuando eso pase, las bibliotecas se derretirán y las aplicaciones flotarán sobre arenas movedizas de stacks tecnológicos más eficientes, seguros e integrados, pero completamente inhumanos.
    En términos de interpretabilidad o seguridad, claramente es una idea aterradora, pero tampoco es tan fácil afirmar que no puede funcionar, sobre todo si hay un esfuerzo centralizado y dedicado detrás. Tampoco está claro que una slopificación total impulsada por máquinas, reescribiendo por completo décadas de desarrollo básico e incremental, y la interpretabilidad sean necesariamente excluyentes.
 
GN⁺ 2 시간 전
Opiniones de Lobste.rs

  • Como referencia, esto es lo que dijo Jarred Sumner sobre el tema en HN: trabaja en Bun, esta es su rama, y su postura es que este hilo es una sobrerreacción a código que no funciona
    Todavía no han decidido definitivamente reescribirlo, y también dice que es muy probable que todo este código termine desechándose
    Quiere ver cómo se ve una versión que funcione, qué rendimiento tiene, qué tan difícil sería hacer que pase la suite de tests de Bun y mantenerla, y poder comparar lado a lado una versión en Rust y una versión en Zig que sean viables

    • Me recuerda la frase de que “una mentira da media vuelta al mundo mientras la verdad se está poniendo los zapatos”
      Las interpretaciones tecnológicas al estilo cultura popular suelen apoyarse mucho en la reacción inmediata

  • Incluso los pull requests normales de Bun son bastante caóticos: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    La mayoría los crea @robobun de forma autónoma, verifica duplicados con acciones de GitHub (basadas en Claude), y @coderabbitai junto con @claude los revisan
    Mientras tanto, el CI está roto, y @robobun termina cerrando parte de sus propios PR porque resultan duplicados de otros PR que él mismo creó
    Los merges a main todavía los hace una persona

    • Esto no me lo esperaba
      Recuerdo que Bun era elogiado por la obsesión por el rendimiento de Jarred, pero no imaginaba que dejarían que los LLM se descontrolaran así dentro del codebase

  • Esto es una locura
    Si ves el “mapeo de modismos”, está lleno de unsafe, y parece que va a salir una gran cantidad de código poco idiomático en Rust
    El mapeo de @fieldParentPtr("field", ptr) en particular se ve bastante tosco
    Aun así, parece que la “fase A” es básicamente una traducción línea por línea, y luego quieren refactorizarlo con prompts hacia un Rust más idiomático y mantenible
    El problema es que el diseño del lenguaje puede empujar muy fuerte la dirección de implementación, y de hecho lo hace, así que es muy probable que se formen enredos difíciles de deshacer después
    Al final, parece que una reescritura manual a la antigua habría sido un mejor camino

    • Hacerlo idiomático y seguro tal vez sea algo que el LLM pueda hacer en la siguiente etapa
      Sobre todo con el nivel de financiamiento de Anthropic, una de las ventajas prácticas de la IA es que no se cansa de refactorizar el mismo código una y otra vez

  • Independientemente de la migración en sí, el método que eligieron es particularmente interesante
    El docs/PORTING.md enlazado tiene unas 300 reglas de porting, y parecen demasiadas para que cualquier LLM las “recuerde” todas y las siga fielmente
    Como Anthropic es dueño de Bun, este porting probablemente tiene en la práctica un presupuesto de tokens casi infinito, y quizá intenten “garantizar” que se cumplan todas lanzando tantos agentes como número de archivos * número de reglas
    Además dividieron el porting en dos etapas: A porta cada archivo de forma aislada y burda, asumiendo que la compilación se romperá; B conecta todo para que compile
    En la fase A le dicen al agente que el código “no necesita compilar”, y hacen que califique cada archivo portado como calidad baja/media/alta según el resultado
    Baja significa que la lógica está mal, media que la lógica está bien pero no compila, y alta que la lógica está bien y parece que sí compilaría
    Esto es casi lo opuesto a cómo yo entiendo y uso los agentes de programación, así que me intriga el resultado
    Mi intuición es que, si le dices que no necesita compilar y no le das una “meta de salida” clara, el resultado se vuelve muy impredecible, y en la fase B terminarás revisando una montaña de código poco confiable
    Hice un grep rápido y, de 1279 de estas calificaciones de calidad de salida, cerca del 3% eran bajas, 80% medias y 17% altas

    • Para mayo de 2026, 300 reglas se ven razonables
      PORTING.md tiene unos 16k tokens y está enfocado en la tarea principal
      Para un subagente nuevo no está nada mal, e incluso podría ser ideal

  • Me pregunto si de verdad quieren una migración a Rust, o si esto es una prueba de los LLM de Anthropic

  • Se ve bastante interesante
    El conjunto de reglas que hay que aplicar de una sola vez parece imposible de verificar sin pasar por un ciclo enorme de revisión de código
    Habrá muchos tokens, pero después de una transformación así, validar el código se volvería realmente muy difícil
    Si los tests también tienen que pasar por el mismo proceso, entonces uno se pregunta qué queda al final como fuente de verdad
    Aun así, como experimento es impresionante

  • Viendo cómo van los supuestos killers de Node.js, Deno ofreció mejoras menores como sistema de permisos o soporte nativo de TypeScript, pero no logró sacudir el mundo, y varias de esas funciones además se están reimportando a Node.js
    Por lo que lo he usado, la experiencia de desarrollador no era significativamente mejor, y a veces incluso peor por herramientas excelentes como pnpm
    Puede ser más rápido, pero en mis casos de uso durante los últimos 5 o 6 años no he sentido realmente problemas de rendimiento con Node.js
    JSR tampoco cambió el panorama, y en cambio la comunidad creó npmx, que ahora ofrece una mejor experiencia
    Eso sí, la librería estándar de Deno, por ejemplo @std/collections, me parece bastante buena y la uso
    Bun siempre tuvo demasiada amplitud de alcance, así que desde el principio había muchas señales de alerta, pero era cautelosamente optimista porque parecía que Jarred quería construir el mejor runtime JS todoterreno, aunque le tomara años
    Pero después de la adquisición por Anthropic, viendo que Jarred ahora hace bastante ~~vibecoding~~ desarrollo basado en agentes, y con esta noticia del vibe porting, se me confirma que no es un proyecto que yo usaría, incluso si solo es una rama experimental
    Así que Node.js sigue dominando
    Hablando en serio, las funciones integradas de TypeScript y SQLite son impresionantes
    No soy completamente anti-IA; me parece divertido y útil hacer vibecoding de pequeños scripts en Python o webapps para resolver problemas muy específicos
    Pero en proyectos complejos con muchas piezas móviles y usuarios, cada vez me convenzo más de que el “desarrollo basado en agentes” a gran escala, aunque pueda acelerar temporalmente el desarrollo de funcionalidades, al final es una pérdida neta que vuelve los proyectos inestables y los infla
    Pienso en ejemplos como VSCode, Cursor, mise y la web UI de Perplexity
    ¿De verdad es tan difícil hacer un dropdown en JS que no se trabe al hacer scroll?
    Ojalá más herramientas, librerías y proyectos grandes de los que dependo se den cuenta y adopten políticas anti-IA más estrictas

  • Literalmente es la dirección equivocada
    No he visto ni un solo mantenedor de Rust que mantenga un proyecto mediano, o sea, de cientos de miles de líneas o más, y esté satisfecho con su escalabilidad en codebases grandes

    • Mucho gusto
      Yo sí creo que Rust es especialmente bueno para codebases grandes:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      Aunque para manejarlo de forma eficiente sí necesitas saber más o menos lo que estás haciendo:
      https://matklad.github.io/2021/09/05/Rust100k.html
      En ese contexto, no sé muy bien cómo se compara Zig frente a Rust
      TigerBeetle tiene una forma de diseñar bastante particular
    • Para dar contexto, he mantenido alrededor de 6 codebases de Rust de entre 10 mil y 100 mil líneas, aunque ninguna supera las 100 mil
      También conozco varios casos de programas en Rust de 20 mil líneas que implementan la funcionalidad central de programas en Go de 300 mil líneas
      Así que no cumple exactamente la condición que mencionaste
      Pero en el rango de 10 mil a 100 mil líneas, como mantenedor estoy muy satisfecho con Rust
      Ese tamaño es lo bastante pequeño para que el programa siga siendo enfocado, pero también lo bastante grande para implementar bien una idea central
      En esa escala, tanto el lenguaje como las herramientas han sido grandes activos, al menos en mi experiencia personal
    • cargo-nextest actualmente tiene 84k líneas de código Rust si excluyes comentarios y líneas en blanco, y como único mantenedor no creo que pudiera escribirlo en otro lenguaje con el nivel de calidad que me exijo

  • Tal vez sea por esto: https://github.com/oven-sh/bun/issues/28001

    • Me gustaría que explicaran exactamente cómo Rust habría detectado esto
      No es un problema de seguridad temporal de memoria