Claude Code verwendet Bun, neu in Rust geschrieben

 (simonwillison.net)
2 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Seit Claude Code v2.1.181 ist das nach Rust portierte Bun integriert; dadurch ist der Start unter Linux 10 % schneller, die meisten Nutzer bemerken die Änderung jedoch kaum
  • Untersucht man die Strings der ausführbaren Datei, lassen sich Bun v1.4.0, das noch kein offizielles Tag hat, sowie Pfade zu Rust-Quelldateien erkennen
  • In ~/.local/bin/claude wurden 563 .rs-Dateinamen gefunden, darunter src/runtime/bake/dev_server/mod.rs
  • Die integrierte Version lässt sich auch verifizieren, indem man per BUN_OPTIONS eine TypeScript-Datei vorlädt und Bun.version ausgibt; sie ist 1.4.0
  • Die Rust-Version wurde als Bun Canary verteilt und läuft über Claude Code bereits auf Millionen von Geräten in Produktion

In Claude Code integriertes, Rust-basiertes Bun

  • Laut Rewriting Bun in Rust verwendet Claude Code seit der am 17. Juni veröffentlichten Version v2.1.181 den Rust-Port
    • Der Start unter Linux wurde um 10 % schneller
    • Andere Unterschiede bemerkten Nutzer kaum; Jarred Sumner bewertete das als „Boring is good“
    • Über Claude Code läuft es bereits auf Millionen von Geräten in Produktion
  • In den Strings der ausführbaren Claude-Datei lässt sich die integrierte Bun-Version finden
strings ~/.local/bin/claude | grep -m1 'Bun v1'
  • In einer macOS-arm64-Umgebung wird Bun v1.4.0 (macOS arm64) ausgegeben
  • Da das neueste offizielle Release auf GitHub zu diesem Zeitpunkt Bun v1.3.14 vom 12. Mai war, enthält Claude Code damit eine noch nicht offiziell veröffentlichte v1.4.0-Preview
  • Die Rust-Version wurde als Bun Canary veröffentlicht und kann mit bun upgrade --canary installiert werden

Rust-Quellen und Versionsprüfung

  • Extrahiert man die Rust-Quellpfade aus der ausführbaren Datei, lassen sich 563 Dateinamen finden
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
  • Die Liste enthält unter anderem folgende Pfade
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
  • Die von Ajan Raj geteilte Methode lädt per BUN_OPTIONS eine TypeScript-Datei vor und gibt die in Claude Code integrierte Bun.version direkt aus
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
  • Auch dieser Befehl gibt 1.4.0 aus
  • In einem Commit vom 17. Mai wurde die package.json-Version auf 1.4.0 geändert und seither beibehalten; sie ist bislang in keinem Tag-Release außer canary enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Meinungen auf Hacker News

  • Es ist schwer nachzuvollziehen, warum ein TUI über JavaScript in React für das Terminal laufen muss. Dass Anthropic zur Verbesserung des TUI sogar die Runtime übernommen hat, lässt die Engineering-Qualität noch zweifelhafter erscheinen. Wenn ein Rewrite so einfach wäre, wäre es deutlich günstiger gewesen, Claude Code in eine native Sprache zu portieren.

    • Da es bereits gut funktioniert und ein Geschäft mit enormem Umsatz ist, ist „Warum diese Technologie?“ eher eine geschäftliche Entscheidung als eine technische. Die am Anfang gewählte Technologie erfüllt ihren Zweck, daher gibt es wenig Grund, sie zu ändern, auch wenn die Architektur nicht perfekt ist.
      Ein Rewrite ist selbst bei Bun nicht einfach; ein Nicht-UI-Entwicklungstool mit klaren API-Verträgen und Tests ist nach einem Rewrite leichter vertrauenswürdig als ein UI-Tool mit unklaren Funktionen und wenigen Tests.
    • Wenn man Claude, OpenCode und Ghostty zusammen verwendet, verbrauchen interaktive Terminalprogramme extrem viel CPU und Akku, und selbst ein Laptop, der über Nacht im Energiesparmodus war, wird heiß. Bei über 40 Jahren Vorbildern wie curses/ncurses, Emacs, Vim und MS-DOS fragt man sich, warum Webtechnologien mit Gewalt hineingezwängt wurden.
    • Ich habe einen Beitrag gesehen, wonach ein bekanntes Haskell-Unternehmen wegen der Geschwindigkeit iterativer Entwicklung mit LLM-Unterstützung auf Python umgestiegen ist. Es gibt sehr viele Trainingsdaten zu React, und die Kompilierzeit von TypeScript ist im Vergleich zu Rust usw. kurz.
      Nutzerseitiger Code und schnell wechselnde UX-Schichten werden vermutlich in dynamische Systeme wandern, die schnelle Iteration ermöglichen, während Infrastrukturschichten in sichere Systemumgebungen wie Rust gehen. Java/C# liegen in der Mitte, aber künftig dürften TypeScript/Python für UX ausreichen und Rust für Systemarbeit besser geeignet sein, sodass ihre Position schwächer wird.
      https://avi.press/posts/2026-07-10-after-7-years-in-producti...
    • Wenn man davon ausgeht, dass Anthropic Claude Code mit AI schreibt, ist JavaScript keine schlechte Wahl. Es gibt reichlich Trainingsdaten, und man vermeidet Probleme mit Multithreading und Speicherverwaltung, die AI in anderen Hochleistungssprachen verwirren könnten; dadurch eignet es sich gut, um mit AI schnell Software zu bauen.
    • OpenAI hat vor etwa einem Jahr beschlossen, Codex in Rust neu zu schreiben. Wenn Rewrites wirklich so einfach sind, müsste man auch fragen, warum Bun nötig ist und warum nicht der gesamte JavaScript-Code nach Rust portiert wird.
      https://github.com/openai/codex/discussions/1174

  • Wenn man Jarreds Originaltext liest, scheint der Grund für den Wechsel klar zu sein: Was in Zig Handarbeit war, wird in Rust automatisiert. Sowohl Menschen als auch Agents sind nichtdeterministisch; wenn man in Zig Speicherlebensdauern und explizites Freigeben manuell nachverfolgt, häufen sich über lange Zeit übersehene Bugs an. Rust eliminiert diese Fehlerklasse und ist damit aus Sicht des Engineering-Managements ein guter Kompromiss.
    Besonders Compilerfehler sind deterministische Sicherheitsnetze, die Coding-Agents brauchen; wenn man Claude eine Möglichkeit gibt, Korrektheit zu testen, und das Ziel „mach es kompilierbar“, funktioniert das gut. Den allgemeinen Ansatz, probabilistische Ausgaben durch deterministische Tests in belastbare Garantien zu verwandeln, habe ich hier zusammengefasst: https://michael.roth.rocks/blog/verification-surface/

    • Zig und C eignen sich nicht gut, wenn man viele kleine Allokationen erzeugt, deren Lebensdauern unabhängig voneinander sind. Für robuste Nutzung muss man Lebensdauern selbst verwalten, etwa indem man Allokationen in Arenas bündelt oder feste Buffer verwendet.
      So kann Zig genauso robust sein wie Rust, aber wenn man ein Allokationsmuster wie in Managed Languages möchte, wie es LLMs bevorzugen, passt Zig nicht.
    • Was automatisch erledigt, sind Sprachen mit Garbage Collection. Auch in Rust muss man über Speicherlebensdauern nachdenken und sie verfolgen, aber der Borrow Checker verhindert falsche Behandlung und gibt sofortiges Feedback zur Korrektur, was es für LLMs angenehm macht. Standardmäßig unveränderliche Referenzparameter verhindern außerdem größere Performanceprobleme.
    • Da Bun derzeit sehr viel unsafe Rust enthält, frage ich mich, ob man wirklich sagen kann, dass eine Fehlerklasse automatisch eliminiert wird: https://news.ycombinator.com/item?id=48967630
    • Meiner Erfahrung nach finden LLMs Speicherfehler ziemlich leicht. Das Ganze wirkt auf mich lediglich wie eine erfolgreiche Marketingaktion von Anthropic.
    • Soweit ich mich erinnere, bestand dieser Rust-Rewrite komplett aus unsafe, daher dürfte dieses Problem vermutlich nicht automatisch beseitigt werden.

  • Unabhängig von Jarreds oder Simon Willisons Einschätzung sehe ich das Ganze ziemlich negativ. Das größere Problem als Anthropics Bun-Übernahme oder der AI-Rewrite ist die unreife Vorgehensweise: angefangen bei der Haltung „Das ist nur mein Branch, ihr überreagiert“ bis hin zum Mergen eines PRs mit über einer Million Zeilen in weniger als einem Monat.
    Die Kommunikation war sehr schlecht, hat Vertrauen beschädigt und Spaltung gefördert; ich frage mich, ob es wirklich so schwer gewesen wäre, dem Ansatz zu folgen, den das TypeScript-Team bei 7.0 gewählt hat.

    • Am Ende haben die meisten Claude-Code-Nutzer es entweder nicht bemerkt oder es ist ihnen egal, und diejenigen, die es problematisieren, sind eine winzige Minderheit; praktisch könnte es also unwichtig sein.
    • Auch TS7 ist ein typisches Beispiel dafür, dass man statt einer ernsthaften Architekturprüfung Zeile für Zeile in eine andere Sprache portiert.

  • Das in Claude enthaltene Bun v1.4.0 scheint eine noch nicht veröffentlichte Preview-Version zu sein. Wenn das stimmt, wirkt es, als sei das FOSS-Projekt Bun stillschweigend zu etwas anderem geworden; gut, dass ich die Prüfung nur als TODO stehen ließ und es nicht eingeführt habe.
    Ich kann kein Governance-Dokument für Bun finden und frage mich, ob es nun faktisch eine Struktur ist, in der Anthropic sowohl die Arbeit als auch die Merge-Entscheidungen bestimmt.

    • Ich kann die Schlussfolgerung schwer nachvollziehen, dass ein Projekt stirbt, nur weil es auf Rust umgestellt wird.
    • Der PR ist öffentlich, jeder kann ihn bauen und verwenden; das Anthropic-Team hat sich lediglich entschieden, ihn zuerst zu nutzen.
    • Soweit ich weiß, hängt die Struktur faktisch davon ab, ob Jarred in der jeweiligen Woche bereit ist, etwas anzunehmen. Im Claude-Code-Changelog stand die Versionsänderung auf Bun 1.4.0 schon seit fast einem Monat, aber da der Eintrag von AI geschrieben war, wäre es nicht überraschend, wenn die meisten ihn nicht gelesen hätten.
    • Ich habe ebenfalls die Einführung von Bun geprüft und mich wegen der Instabilität dagegen entschieden; angesichts dieser Sache scheint das die richtige Entscheidung gewesen zu sein.

  • Ich verstehe nicht, warum man das so kompliziert um Bun herum gelöst hat. Wenn ein Agent Zig nach Rust portieren kann, hätte man Claude Code auch direkt von JavaScript nach Rust neu schreiben können, um die Runtime-Abhängigkeit loszuwerden und die Performance zu erhöhen.

    • Wenn man davon ausgeht, dass Buns Rust-Rewrite praktisch nichts mit Anthropics Produktstrategie zu tun hat, gibt es keinen Grund zur Verwirrung.
    • Betrachtet man nur Claude Code, wäre ein direkter Rewrite in Rust besser gewesen; dann würde aber der Wert der Übernahme von Bun/oven.sh stark sinken.
      Bun dürfte neben Claude Code auch externe sowie interne Nutzer bei Anthropic haben und verschafft ihnen ein JavaScript-Runtime- und Tool-Ökosystem, das Coding-Modelle bevorzugen könnten. Künftig könnte Anthropic sogar eine Cloud anbieten, die auf das Ausführen und Verwalten solcher Apps spezialisiert ist; allein durch den Zugang zur Entwickler-Community hätte das deutlich mehr Wirkung, als nur Claude Code nach Rust zu portieren.
    • Fraglich ist auch, ob Claude Code tatsächlich durch Performance ausgebremst wird. Eine JavaScript-Runtime hat ein großes Tool-Ökosystem und macht Plugin-Entwicklung leicht, also ist sie völlig angemessen.

  • Lässt man Spekulationen und Emotionen weg, interessiert vor allem die tatsächliche Ausführungsqualität. Man sollte nicht nur die Startgeschwindigkeit prüfen, sondern auch RAM- und CPU-Verbrauch sowie das Verhalten bei Endlosschleifen oder Deadlocks; wenn es gleich gut oder besser ist als vorher, wäre das ziemlich beeindruckend.
    Als Entwickler gefällt mir die Möglichkeit nicht, dass AI Jobs übernimmt. Aber wenn jeder mit einfachen Anforderungen die gewünschte Software bauen kann, könnte das die Welt verbessern. Wenn einem Microsofts Datensammlung missfällt, lässt man sich von AI ein Betriebssystem bauen; wenn einen Googles Abhören stört, ein Mobiltelefon – eine solche technische Selbstversorgung könnte möglich werden, und dagegen wirkt die eigene Jobsicherheit nebensächlich.
    Deshalb ist es umso wichtiger, die Technologie Open Source zu halten; andernfalls wiederholen wir nur die bestehenden Monopolstrukturen und verlieren zusätzlich Arbeitsplätze.

    • Der schwierigste Teil der Softwareentwicklung ist es, klare Anforderungen zu bekommen. Selbst mit perfekter AGI können Menschen nicht klar ausdrücken, was sie wollen; eine Welt, in der jeder exakt die gewünschte Software bekommt, wird es daher nicht geben.
    • Auch gute Werkzeuge liefern nur in den Händen erfahrener Handwerker hervorragende Ergebnisse. Gute Entwickler stellen die richtigen Fragen, bauen Sicherheitsvorkehrungen ein und können Ergebnisse dort direkt anpassen, wo es nötig ist.
    • Geschlossene Modelle hinter einer subventionierten Paywall heute als Demokratisierung der Technologie zu bezeichnen, ist ziemlich naiv. Die Strategie, Buns Rust-Portierung vor allem für Marketingzwecke zu nutzen, scheint gut funktioniert zu haben.

  • Kürzlich hatte ich bei der Nutzung von Claude Code in einem Kitty-Tab einen Segmentation Fault; danach reagierte der ganze Tab nicht mehr auf Eingaben. Es erscheint zwar ein Link zum Melden, aber man kann ihn nicht anklicken, und er ist codiert, sodass nicht erkennbar ist, welche Informationen gesendet werden.

    • Bun ist bei Ideen und Funktionen anderen JavaScript-Runtimes haushoch überlegen, aber die Stabilität ist miserabel, und es gab etwa 20-mal mehr Segmentation Faults als bei Node. Diese Zahl basiert auf Telemetriedaten von New Relic.
    • Wenn in der Shell nicht Segmentation fault ausgegeben wurde, war es wahrscheinlich kein Segmentation Fault, sondern ein Hänger. Bei einem echten Fehler kann man nach der Rückkehr zur Shell reset eingeben, auch wenn es nicht auf dem Bildschirm zu sehen ist, um den Tab wiederherzustellen.
    • Auf meinem Arbeits-MacBook nutze ich Ghostty und Claude Code, habe dieses Problem aber noch nicht erlebt. Früher gab es ein ausuferndes Memory Leak, das das System zum Stillstand brachte und einen Neustart nötig machte; in den letzten Wochen ist es verschwunden. Es ist noch zu früh für eine definitive Aussage, aber die Rust-Portierung könnte das Memory Leak reduziert haben.
    • In Ghostty hängt es sich bei Claudes interaktiver Frageoberfläche ähnlich auf; außer Scrollen wird keine Eingabe akzeptiert, einschließlich Auswahl oder Abbruch. Ich glaube allerdings nicht, dass das mit Bun zusammenhängt.
    • Auch die Zig-Version hatte Segmentation Faults, und wenn man sie Zeile für Zeile nach unsafe Rust übertragen hat, bleibt der verursachende Code ebenfalls erhalten. Das wird nicht gelöst sein, bevor er zu idiomatischem, speichersicherem Rust refaktoriert wurde.

  • Sie wirken wie extrem erfolgreiche, aber schlechte Ingenieure, die Probleme gut beschreiben können und ein unbegrenztes Token-Budget haben. Wenn sie die Token-Kosten selbst tragen müssten, hätten sie einen finanziellen Anreiz, die Software effizienter zu machen.
    Die verborgene Realität von AI-Rechenzentren ist, dass die Effizienz von GPU-Clustern selbst bei nur 40–60 % einfach dadurch kompensiert wird, dass man mit Geld mehr Hardware kauft. Der Grund für die Angst vor chinesischen Wettbewerbern könnte auch sein, dass diese sich solche Verschwendung nicht leisten können.

  • Diese Arbeit ist Transpiling, und die Qualität ist auch nicht gut. Der erzeugte Code ist weit von idiomatischem Rust entfernt und kann durchaus als hässlich gelten.

    • Trotzdem scheint er ordentlich zu funktionieren. Dies ist im Grunde die erste Phase einer mechanischen Zeile-für-Zeile-Übertragung; in der nächsten Phase soll sie zu idiomatischem Rust verfeinert werden. Daher wirkt es nicht ratsam, weiter gegen diesen Rewrite zu wetten.
    • Mit Blick auf Stabilität, Effizienz und Kosten wäre es deutlich sinnvoller gewesen, einen Source-to-Source-Transpiler zu verwenden oder zu schreiben, der die ursprüngliche Struktur möglichst bewahrt.
      Normalerweise fließen bei einem Rewrite die Lehren aus der bestehenden Codebasis ein; wenn Agenten Datei für Datei portieren, hat man diesen Vorteil nicht. In beiden Fällen entsteht eine unidiomatische Übersetzung, aber mit einem LLM kommen Nichtdeterminismus und enorme Kosten hinzu.
    • Es braucht konkrete Beispiele für den angeblich hässlichen Rust-Code.
    • Ich frage mich, warum man nicht lieber direkt nach LLVM IR transpiliert hat.
    • Wenn das Projekt sein Ziel der Speichersicherheit erreicht, ist fraglich, ob idiomatischer Code wirklich so wichtig ist.

  • In letzter Zeit ist Claude Code deutlich instabiler als früher, und durch TUI-Renderingfehler wird der Gesprächsverlauf häufig beschädigt.

    • Seit Februar nutze ich Claude widerwillig, und von Anfang an war es mit Rendering-Defekten, Tastatureingabefehlern und Ähnlichem die schlechteste TUI, die ich je verwendet habe. Trotzdem ist es in der letzten Woche noch schlimmer geworden: Teile der eingegebenen Zeichen werden nicht angezeigt, und es fängt an, ganze Terminal-Sessions zu ruinieren.
      Wenn man es in den Hintergrund schickt, reset ausführt und es wieder in den Vordergrund holt, ist es behoben. Als ich Claude um eine Diagnose bat, sagte es, bei ihm gebe es solche Bugs nicht und ein anderes Programm sei schuld, obwohl nur tmux und Claude liefen. Falls kürzlich die Rust-Version ausgerollt wurde, passt das zeitlich ungefähr zum Qualitätsabfall.
    • Unter Windows wird die Ausgabe jedes Mal völlig zerstört, wenn man die Fenstergröße ändert, sodass man die gerade gegebene Antwort erneut anfordern muss. Das ist kein neues Problem, fühlt sich aber in letzter Zeit schlimmer an.
    • Ich bin nicht grundsätzlich gegen AI, aber Anthropic geht zu weit und liefert von AI erzeugten Code niedriger Qualität aus. Echte Ingenieure müssen weiterhin eingreifen und die Tools lenken; Anthropic scheint jedoch 100 % des Codes der AI überlassen zu wollen.