2 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • A partir de Claude Code v2.1.181, incorpora Bun portado a Rust, lo que aceleró en 10% el arranque en Linux, aunque la mayoría de los usuarios casi no notó el cambio
  • Al inspeccionar las cadenas del ejecutable, se puede identificar Bun v1.4.0, que aún no tiene una etiqueta oficial, y rutas de archivos fuente en Rust
  • En ~/.local/bin/claude se encontraron 563 nombres de archivos .rs, incluidos src/runtime/bake/dev_server/mod.rs y otros
  • También se puede verificar que la versión integrada es 1.4.0 precargando un archivo TypeScript con BUN_OPTIONS para imprimir Bun.version
  • La versión en Rust se distribuyó como Bun canary y ya se ejecuta en producción en millones de dispositivos a través de Claude Code

Bun basado en Rust integrado en Claude Code

  • Según Rewriting Bun in Rust, desde Claude Code v2.1.181, lanzado el 17 de junio, se usa el port a Rust
    • El arranque en Linux mejoró 10%
    • Los usuarios casi no notaron otras diferencias, y Jarred Sumner lo calificó como “Boring is good”
    • Ya se ejecuta en producción en millones de dispositivos a través de Claude Code
  • Se puede encontrar la versión integrada de Bun en las cadenas del ejecutable de Claude
strings ~/.local/bin/claude | grep -m1 'Bun v1'
  • En un entorno macOS arm64, imprime Bun v1.4.0 (macOS arm64)
  • Dado que la versión estable más reciente en GitHub en ese momento era Bun v1.3.14, del 12 de mayo, Claude Code incluye una vista previa de v1.4.0 que aún no se lanzó oficialmente
  • La versión en Rust se publicó como Bun canary y se puede instalar con bun upgrade --canary

Verificación del código fuente en Rust y de la versión

  • Al extraer las rutas del código fuente en Rust desde el ejecutable, se pueden identificar 563 nombres de archivos
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
  • La lista incluye las siguientes rutas
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
  • El método compartido por Ajan Raj precarga un archivo TypeScript con BUN_OPTIONS e imprime directamente Bun.version integrado en Claude Code
cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version
  • Este comando también imprime 1.4.0
  • En el commit del 17 de mayo, la versión de package.json se cambió a 1.4.0 y se mantuvo así; todavía no se incluye en ningún lanzamiento con etiqueta fuera de canary

1 comentarios

 
GN⁺ 1 일 전
Comentarios en Hacker News
  • Cuesta entender por qué una TUI tiene que pasar por JavaScript y ejecutarse en React para terminal. Que Anthropic haya adquirido incluso un runtime para mejorar la TUI me hace dudar aún más de la calidad de ingeniería. Si reescribir fuera tan fácil, habría sido mucho más barato mover Claude Code a un lenguaje nativo

    • Como ya es un negocio que funciona bien y genera ingresos enormes, la pregunta de “¿por qué esta tecnología?” está más cerca de una decisión de negocio que de una técnica. La tecnología elegida al inicio está cumpliendo su función, así que aunque la arquitectura no sea perfecta hay pocos motivos para cambiarla
      Reescribir no es fácil ni siquiera para Bun, y una herramienta de desarrollo sin UI con contratos de API y pruebas claras es más fácil de confiar tras una reescritura que una herramienta de UI con funcionalidades ambiguas y pocas pruebas
    • Si usas Claude, OpenCode y Ghostty juntos, los programas de terminal interactivos consumen muchísimo CPU y batería, y hasta una laptop que estuvo en suspensión toda la noche termina caliente. Hay más de 40 años de precedentes con curses/ncurses, Emacs, Vim y hasta MS-DOS, así que me pregunto por qué forzaron tecnologías web aquí
    • Vi una publicación sobre una conocida empresa de Haskell que se pasó a Python por la velocidad de desarrollo iterativo usando LLM. Hay muchísimos datos de entrenamiento para React, y el tiempo de compilación de TypeScript también es más corto que en Rust y otros
      El código de cara al usuario y la capa de UX que cambia rápido probablemente se moverán a sistemas dinámicos que permiten iteración rápida, mientras que la capa de infraestructura irá a entornos de sistemas seguros como Rust. Java/C# quedan en el punto medio, pero parece que a futuro TypeScript/Python bastarán para UX y Rust será más adecuado para trabajo de sistemas, así que su espacio podría reducirse
      https://avi.press/posts/2026-07-10-after-7-years-in-producti...
    • Si asumimos que Anthropic escribe Claude Code con IA, JavaScript tampoco es una mala elección. Tiene abundantes datos de entrenamiento y además evita problemas de multihilo y gestión de memoria que podrían confundir a la IA en otros lenguajes de alto rendimiento, así que sirve bien para crear software rápido con IA
    • OpenAI decidió hace alrededor de un año reescribir Codex en Rust. Si reescribir de verdad fuera tan fácil, entonces también habría que preguntar por qué hace falta Bun y por qué no mueven todo el código JavaScript a Rust
      https://github.com/openai/codex/discussions/1174
  • Al leer el texto original de Jarred, parece claro que el motivo del cambio es que en Rust se automatizan partes que en Zig eran manuales. Tanto humanos como agentes son no deterministas, así que al rastrear manualmente la vida útil de memoria y la liberación explícita en Zig se van acumulando durante mucho tiempo bugs por omisión, mientras que Rust elimina esa clase de errores y se vuelve una buena solución de compromiso desde la gestión de ingeniería
    En particular, los errores del compilador son una protección determinista necesaria para agentes de programación, y Claude funciona bien si le das una forma de poner a prueba la corrección y el objetivo de “haz que compile”. Un enfoque generalizado para convertir salidas probabilísticas en garantías firmes mediante pruebas deterministas está resumido en https://michael.roth.rocks/blog/verification-surface/

    • Zig y C no son adecuados cuando se crean muchas asignaciones pequeñas con vidas útiles no relacionadas entre sí. Para usarlos de forma sólida hay que gestionar directamente la vida útil, por ejemplo agrupando asignaciones en arenas o usando buffers fijos
      Haciendo eso, Zig puede ser tan robusto como Rust, pero si lo que se quiere es el patrón de asignación estilo lenguaje administrado que prefieren los LLM, Zig no encaja
    • Lo que lo maneja automáticamente son los lenguajes con recolección de basura. Incluso en Rust hay que pensar y rastrear la vida útil de la memoria, pero el borrow checker evita manejos incorrectos y da retroalimentación inmediata para corregirlos, así que es cómodo para que lo escriba un LLM. Los parámetros de referencia inmutable por defecto también ayudan a prevenir grandes problemas de rendimiento
    • Actualmente Bun tiene muchísimo Rust unsafe, así que dudo que se pueda decir que elimina automáticamente clases de errores: https://news.ycombinator.com/item?id=48967630
    • En mi experiencia, los LLM detectan bugs de memoria con bastante facilidad. Todo esto me parece solo un exitoso evento de marketing de Anthropic
    • Recuerdo que esta reescritura en Rust fue toda unsafe, así que es muy probable que no elimine ese problema automáticamente
  • Independientemente de la opinión de Jarred o Simon Willison, veo todo esto bastante negativamente. Más que la compra de Bun por Anthropic o la reescritura con IA, el problema mayor es la forma inmadura en que se llevó esto, empezando por la actitud de “es solo mi rama y están exagerando” y terminando con la fusión de un PR de más de 1 millón de líneas en menos de un mes
    La comunicación fue muy mala, dañó la confianza y profundizó la división, y me pregunto si de verdad era tan difícil seguir el enfoque que tomó el equipo de TypeScript en 7.0

    • Al final, puede que en la práctica no importe porque la mayoría de los usuarios de Claude Code no lo notaron o no les importa, y quienes lo cuestionan son una minoría muy pequeña
    • TS7 también es un caso representativo de portar línea por línea a otro lenguaje en lugar de revisar seriamente la arquitectura
  • Parece que Bun v1.4.0 incluido en Claude es una versión preliminar todavía no publicada. Si es así, el proyecto FOSS Bun parece haber cambiado silenciosamente a otra cosa, así que me alegra haber dejado su adopción solo como una tarea pendiente de investigación y no haberlo implementado
    No encuentro un documento de gobernanza de Bun, así que me pregunto si ahora en la práctica Anthropic decide tanto el trabajo como qué se fusiona

    • Me cuesta entender la conclusión de que cambiar a Rust significa que el proyecto está muerto
    • El PR está público, así que cualquiera puede compilarlo y usarlo; simplemente el equipo de Anthropic decidió usarlo primero
    • Según entiendo, en la práctica depende de si Jarred está dispuesto a aceptarlo esa semana. El registro de cambios de Claude Code ya mencionaba el cambio de versión a Bun 1.4.0 desde hacía casi un mes, aunque no sería raro que casi nadie lo leyera por estar escrito por IA
    • Yo también investigué adoptar Bun, pero decidí no usarlo por su inestabilidad, y viendo esto parece que fue la decisión correcta
  • No entiendo por qué complicaron tanto esto alrededor de Bun. Si el agente puede pasar Zig a Rust, también podrían haber reescrito Claude Code directamente en Rust desde JavaScript para eliminar la dependencia del runtime y mejorar el rendimiento

    • No hay motivo para confundirse si se asume que la reescritura de Bun en Rust prácticamente no tiene nada que ver con la estrategia de producto de Anthropic
    • Viéndolo solo desde Claude Code, habría sido mejor una reescritura directa en Rust, pero entonces el valor de adquirir Bun/oven.sh se reduciría mucho
      Bun probablemente tenga usuarios externos y también internos en Anthropic, y les da control sobre un runtime de JavaScript y un ecosistema de herramientas que los modelos de código podrían preferir. A futuro, Anthropic incluso podría ofrecer una nube especializada en ejecutar y administrar este tipo de apps, y con solo ganar una comunidad de desarrolladores obtendría una influencia mucho mayor que moviendo solo Claude Code a Rust
    • También es dudoso que Claude Code realmente tenga un cuello de botella de rendimiento. Los runtimes de JavaScript tienen un gran ecosistema de herramientas y facilitan el desarrollo de plugins, así que son suficientemente adecuados
  • Dejando de lado las suposiciones y las emociones, lo que da curiosidad es la calidad real de ejecución. Hay que revisar no solo la velocidad de arranque, sino también el uso de RAM y CPU, y cómo se comporta ante bucles infinitos o interbloqueos; si está igual o mejor que antes, sería bastante impresionante
    Como desarrollador, no me gusta la posibilidad de que la IA se lleve los empleos, pero si cualquiera pudiera crear el software que quiere con solo requisitos simples, eso podría mejorar el mundo. Si no te gusta la recolección de datos de Microsoft, podrías hacerle crear a una IA tu sistema operativo; si no te gusta que Google te escuche, podrías hacerle crear tu teléfono, y eso permitiría una autosuficiencia técnica frente a la cual la estabilidad laboral individual se vuelve algo menor
    Por eso es aún más importante mantener la tecnología como open source; de lo contrario, repetiremos la estructura monopólica actual mientras además perdemos empleos

    • La parte más difícil del desarrollo de software es obtener requisitos claros. Incluso con una AGI perfecta, la gente no puede expresar con claridad lo que quiere, así que no llegará un mundo donde todos creen exactamente el software que desean
    • Incluso una buena herramienta necesita un artesano hábil para producir resultados sobresalientes. Un buen desarrollador hace las preguntas correctas, establece salvaguardas y puede ajustar directamente el resultado donde haga falta
    • Llamar democratización tecnológica a modelos cerrados detrás de un muro de pago subsidiado es demasiado ingenuo. Parece que la estrategia de usar sobre todo con fines de marketing la migración de Bun a Rust sí les funcionó
  • Hace poco, usando Claude Code dentro de una pestaña de Kitty, tuve un segmentation fault, y después toda la pestaña dejó de responder a la entrada. Aparece un enlace para reportarlo, pero no se puede hacer clic y además está codificado, así que ni siquiera se puede verificar qué información envía

    • En ideas y funciones, Bun es muchísimo mejor que otros runtimes de JavaScript, pero su estabilidad es pésima, y tuvo unas 20 veces más segmentation faults que Node. Esa cifra se basa en datos de telemetría remota de New Relic
    • Si la shell no mostró Segmentation fault, es más probable que no haya sido un segmentation fault sino un cuelgue. Si fuera un error real, al volver a la shell podrías recuperar la pestaña escribiendo reset, aunque no se vea en pantalla
    • Uso Ghostty y Claude Code en mi MacBook de trabajo, pero todavía no me ha pasado ese problema. Antes había fugas de memoria descontroladas que congelaban el sistema y obligaban a reiniciar, pero desaparecieron en las últimas semanas; aún es pronto para afirmarlo, pero la migración a Rust podría haber reducido las fugas de memoria
    • En Ghostty también se cuelga de forma parecida al usar la interfaz de preguntas interactiva de Claude, y no acepta ninguna entrada salvo el scroll, ni siquiera seleccionar o cancelar. Aun así, no creo que tenga relación con Bun
    • La versión en Zig también tenía segmentation faults, y si eso se pasó línea por línea a unsafe Rust, entonces el código que causaba el problema también siguió ahí. No se resolverá hasta refactorizarlo a un Rust idiomático y seguro en memoria
  • Parecen ingenieros terribles que tuvieron mucho éxito, con capacidad para describir bien los problemas y un presupuesto de tokens ilimitado. Si tuvieran que pagar directamente el costo de los tokens, tendrían un incentivo financiero para mejorar la eficiencia del software
    La realidad oculta de los centros de datos de IA es que, aunque la eficiencia de los clústeres de GPU sea de apenas 40~60%, lo compensan comprando más equipos con dinero. Tal vez una razón por la que temen a competidores chinos es que ellos no tienen margen para desperdiciar así

  • Este trabajo es un transpilado, y la calidad tampoco es buena. El código generado está lejos de ser Rust idiomático y podría llamarse una monstruosidad

    • Aun así, parece funcionar correctamente. Esta vez es básicamente una etapa inicial de traslado mecánico línea por línea, y en la siguiente fase planean pulirlo a Rust idiomático, así que no parece buena idea seguir apostando en contra de esta reescritura
    • Pensando en estabilidad, eficiencia y costo, habría sido mucho más razonable usar o escribir un conversor entre lenguajes fuente que preservara al máximo la estructura original
      Normalmente, en una reescritura se reflejan las lecciones aprendidas del codebase existente, pero si la migración se hace archivo por archivo con un agente, se pierde esa ventaja. En cualquier caso termina siendo una traducción no idiomática, pero con un LLM además se agregan no determinismo y costos enormes
    • Hace falta un ejemplo concreto de ese código Rust monstruoso
    • Me pregunto por qué no transpilarlos directamente a LLVM IR
    • Si el proyecto logra su objetivo de seguridad de memoria, no está claro si realmente importa tanto que el código sea idiomático
  • Últimamente Claude Code está mucho más inestable que antes, y con frecuencia el historial de conversación se corrompe por errores de renderizado en la TUI

    • Llevo usando Claude a regañadientes desde febrero, y desde el principio ha sido la peor TUI que he usado, con defectos de renderizado, errores de entrada por teclado y demás. Pero en la última semana empeoró todavía más y empezó incluso a arruinar sesiones de terminal, por ejemplo dejando de mostrar parte de los caracteres tecleados
      Se arregla mandándolo al background, ejecutando reset y luego trayéndolo otra vez al foreground. Le pedí a Claude que lo diagnosticara y dijo que ese bug no era suyo, sino de otro programa, pero solo estaban corriendo tmux y Claude. Si aplicaron recientemente la versión en Rust, coincide más o menos con el momento en que cayó la calidad
    • En Windows, cada vez que cambio el tamaño de la ventana, la salida se rompe por completo y tengo que pedir otra vez la respuesta que acababa de dar. No es un problema nuevo, pero últimamente se siente peor
    • No estoy en contra de la IA en sí, pero Anthropic se está pasando de la raya y está sacando código de baja calidad hecho por IA. Ingenieros reales deberían seguir interviniendo y guiando la herramienta, pero parece que Anthropic quiere dejar el 100% del código en manos de la IA