Buns experimentelle Rust-Neufassung erreicht 99,8 % Testkompatibilität unter Linux x64 glibc

• Buns Rust-Neufassung besteht unter Linux x64 glibc 99,8 % der bestehenden Test-Suite
• Die Codebasis ist „im Grunde dieselbe Codebasis“, und durch den Wechsel zu Rust erzwingt der Compiler den Lebenszyklus von Typen und ermöglicht den Einsatz von Destruktoren zum nötigen Zeitpunkt
• Unsichere Teile werden in Rust durch unsafe klarer sichtbar, was einen refaktorierungsfördernden Effekt hat
• Der Grund für die Neufassung war, dass man es leid war, viel Zeit damit zu verbringen, sich über Speicherlecks, Abstürze und Stabilitätsprobleme Sorgen zu machen und sie zu beheben, und sich eine Sprache wünschte, die stärkere Werkzeuge bietet, um dies zu verhindern
• Der Gesamtumfang wurde als Neuschreibung von 960.000 LOC beschrieben; unter Linux besteht sie die Test-Suite, weitere Plattformen sollen bald folgen

---

Stand der Rust-Neufassung

• Buns Rust-Neufassung besteht unter Linux x64 glibc 99,8 % der bestehenden Test-Suite
• Die Codebasis ist „im Grunde dieselbe Codebasis“, und durch die Umstellung auf Rust erzwingt der Compiler den Lebenszyklus von Typen und ermöglicht den Einsatz von Destruktoren zum nötigen Zeitpunkt
• Unsichere Teile treten in Rust durch unsafe deutlicher hervor, was einen refaktorierungsfördernden Effekt hat
• Als Hintergrund der Neufassung wurde genannt, dass man es leid war, viel Zeit damit zu verbringen, sich über Speicherlecks, Abstürze und Stabilitätsprobleme Sorgen zu machen und sie zu beheben, und sich eine Sprache wünschte, die stärkere Werkzeuge bietet, um solche Probleme zu verhindern
• Der Gesamtumfang wurde als Neuschreibung von 960.000 LOC beschrieben, und der Code funktioniert tatsächlich, besteht unter Linux die Test-Suite und weitere Plattformen sollen bald folgen

Künftige Veröffentlichungen und Antworten zum Build

• Was das für Bun bedeutet, Benchmarks, Speicherverbrauch, die künftige Wartbarkeit und der tatsächliche Ablauf der Neufassung sollen in separaten Blogbeiträgen behandelt werden
• Der Neufassungsprozess bestand nicht einfach darin, „claude, rewrite bun in rust. make no mistakes“ zu sagen; die Arbeit, um einen bis zum Ende funktionierenden Zustand zu erreichen, begann vor 6 Tagen
• Es wurde angemerkt, dass dies bei rein manueller Arbeit eine enorme Arbeitsmenge gewesen wäre
• Die Kompilierzeit ist grundsätzlich ähnlich wie bei der bestehenden Zig-Version, die den schnelleren Zig-Compiler nutzt; mit dem Upstream-Zig-Compiler hätte der Rust-Port laut Aussage schneller kompiliert
• Die Performance soll in einem separaten Blogbeitrag behandelt werden
• Auf die Frage nach dem nächsten Schritt, libc selbst durch die Rust-Version frankenlibc zu ersetzen, hieß es, man werde davor lieber direkt eine eigene libc bauen

[GN⁺]

Hacker-News-Kommentare

• Schon vor 4 Tagen gab es dazu etwas: https://news.ycombinator.com/item?id=48019226
  Ein Bun-Mitarbeiter sagte, es sei sein eigener Branch; der damalige Thread sei eine Überreaktion auf nicht funktionierenden Code gewesen, man habe sich noch nicht endgültig auf ein Rewrite festgelegt, und es sei gut möglich, dass der Code komplett verworfen werde.
  Man wolle sehen, wie eine funktionierende Version aussieht, wie es um Performance und Wartbarkeit steht und wie schwer es ist, die Bun-Testsuite zu bestehen, um dann die Rust-Version und die Zig-Version direkt nebeneinander zu vergleichen.

  • Als er diese Nachricht schrieb, warf cargo check mehr als 16.000 Compilerfehler aus, und weder Versionsnummern-Ausgabe noch JavaScript-Ausführung funktionierten.
    Er habe nicht erwartet, dass es so schnell lauffähig wird oder dass die Performance so konkurrenzfähig sein würde; Details sollen in einem Blogpost folgen.
  • Es klingt so, als habe man Wartbarkeit, Performance und die Testsuite geprüft und dann eine Entscheidung getroffen.
  • Dann bedeutet das, dass es bislang als Experiment sehr erfolgreich war.
  • Vor ein paar Tagen hieß es außerdem: „Open Source wird wohl in die entgegengesetzte Richtung gehen. Keine menschlichen Beiträge erlaubt. Slop wird die nostalgische Kuriosität von 2025–2026 sein.“
    Nach der Übernahme durch Anthropic hätte man es wohl erwarten müssen, aber es ist trotzdem enttäuschend. Ich bin nicht grundsätzlich gegen Large-Language-Model-Technologie, aber die Art, wie diese „AI“-Firmen Macht gewinnen, indem sie die Softwareindustrie und die Gesellschaft insgesamt vereinnahmen, ist widerlich und schafft eine sehr ungesunde Abhängigkeit.
    Man sollte ein paar Züge vorausdenken und einen Software-Stack und Communities ohne Slop vorbereiten. Dazu gehören auch Zig und sein Ökosystem. Selbst wenn wir und künftige Generationen nicht völlig ohne Slop leben können, ist es wichtiger denn je, eine nachhaltige Computerkultur zu sichern, in der Freiheit als Freiheit erhalten bleibt.

• Dass sie das so schnell geschafft haben, ist äußerst beeindruckend. Ich arbeite seit 5 Monaten an einem ähnlichen Projekt, nämlich TypeScript nach Rust zu portieren, habe aber weder Mythos noch unbegrenzten Token-Zugang.
  Trotzdem bin ich fast bei 100 % Erfolgsquote; zum Zeitpunkt des Schreibens sind es 99,6 %: https://tsz.dev
  Rust eignet sich hervorragend dafür, mit Large Language Models Code zu schreiben. Dank des strengen Typsystems macht man viel seltener völlig dumme Fehler, die in anderen Sprachen durchgehen würden.
  Aber nur weil man Code mit einem Large Language Model schreibt, verschwinden die nötige Architekturvision und die Abwägung von Trade-offs bei der Projektentwicklung nicht. Deshalb sind Jarred und sein Team die richtigen Leute, um mit Large Language Models enorme Mengen Code produktiv einzusetzen.

  • Dass Rust Invarianten zur Compile-Zeit erzwingt, hilft Large Language Models dabei, funktionierenden Code zu erzeugen, weil sie schnelles Feedback bekommen und zurückgehen können.
    Andererseits ist Rust eine komplexe Sprache, in der kleine Änderungen leicht eine Refactoring-Lawine auslösen können, weil weit entfernte Codestellen angepasst werden müssen. Wenn die anfängliche Architektur schlecht oder unzureichend ist, besteht ein großes Risiko, dass die Codebasis immer spaghettihafter wird, je mehr ein Large Language Model sie – wie üblich – inkrementell erweitert.
    Ich sorge mich, dass am Ende Programme entstehen, die zwar kompilieren und laufen, die aber kein Mensch mehr lesen oder warten kann.
  • Ich arbeite ähnlich auch an multithreaded Postgres. Nach einem Monat bestand es bereits 96 % der pg-Regressions-Tests und lag bei 823K LOC.
    Alles ohne Mythos, nur mit acht Codex-Accounts à 200 Dollar pro Monat.
    Auch hier sehe ich die Vorteile von Rust, und auf Basis meiner Postgres-Erfahrung glaube ich, gute Designentscheidungen für mehrere Bereiche treffen zu können, mit denen sich Leute bei pg seit Langem schwertun. Ich finde es spannend, dass AI Verbesserungen an komplexer Software praktikabler macht, die früher unpraktisch gewesen wären.
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Als Microsoft so etwas in Go neu schrieb, nannte einer der Leads die Ähnlichkeit der Paradigmen als Grund, warum man Go statt Rust gewählt habe. Garbage Collection und Ähnliches seien vergleichbar, und Rust wäre schwieriger gewesen und hätte mehr Umwege erfordert. Mich würde interessieren, wie das aus der Sicht von jemandem ist, der es tatsächlich gemacht hat.
  • Rust ist großartig, aber wenn man bei großen Projekten mit Large Language Models Rust-Software bauen will, bricht die gewünschte Arbeitsweise zusammen.
    Selbst saubere Grenzen zu wahren oder überhaupt erst zu schaffen wird statt eines Flow-Zustands zu einer schmerzhaften Review-Aufgabe, und am Ende verfällt man in einen Vermeidungsmodus.
  • Ich hatte Mühe, Opus davon abzuhalten, Rust-Idiome zu ignorieren und möglichst seltsames Rust zu schreiben. Mich würden Tipps dazu interessieren.

• Das ist keine besonders fundierte Position, aber ich will mit Bun nichts mehr zu tun haben. Es ist eher ein Bauchgefühl, aber ich kann ihm weder trauen noch es unterstützen.
  Man hat Zig geforkt, um LLM-Rewrites zu nutzen, und Dinge wie nichtdeterministische Kompilierung gebaut, gegen die das Zig-Team sich offensichtlich gesträubt hat.
  Jetzt macht man jammernd ein LLM-Rewrite in Rust. Es kann gut sein, dass Bun nur deshalb so weit gekommen ist, weil Zigs Designphilosophie schwierige, aber präzise Entscheidungen erzwang, und dass das Rust-Rewrite tatsächlich der Anfang vom Niedergang ist.
  Das ist eher eine politische als eine technische Einschätzung, aber Bun wirkt komplett von Claude getragen. Es würde mich nicht wundern, wenn der nächste Marketing-Slogan von Anthropic lautet: „Claude Mythos rewrites führende 950K-LOC-JS-Runtime in Rust“.

  • Ich weiß nicht, ob der Entwickler, der Code in sein eigenes Repository schreibt, ein jammerndes Baby ist, oder ob es eher die Person auf Hacker News ist, die sich darüber beklagt.
  • Ich habe Jarred nicht jammern sehen; es wirkt, als richte sich der Ärger in die falsche Richtung.
    Der verlinkte Twitter-Thread liefert klare technische Begründungen.
  • Ich hänge persönlich nicht so stark an Bun, aber ich verstehe nicht, warum das so wichtig sein soll. Ich frage mich, ob dieselben Leute ihre anderen Dependencies ebenfalls so überprüfen.
    Im JS/NPM-Ökosystem zu arbeiten bedeutet ohnehin, stark auf bloßen Glauben an nicht verifizierte Dependencies zu setzen, und vor und nach einem LLM-Rewrite sieht das für mich nicht grundlegend anders aus. Wenn die ursprünglichen Ziele und API-Verträge erfüllt werden, macht es dann einen Unterschied? Ich bezweifle auch, dass die Leute den bisherigen Source Code so gründlich gelesen haben.
  • Stimme zu. Bun hatte von Anfang an eine klare Designphilosophie. Es sollte einfach alles liefern, was man wollte: Runtime, Bundler, Testsuite und Paketmanager, dazu wöchentlich Patches, die irgendetwas kaputtmachen.
    Es war jedes Mal die gleiche Erzählung, bestehende Konkurrenz besser, schneller und stärker zu überrollen, aber dass Keep It Simple Stupid dabei niemals gelten würde, war allzu offensichtlich.
    Ebenso klar war, dass man das in naher Zukunft höchstens in YC-Startups im echten Betrieb sehen würde, die wie mit Brandbeschleuniger eines nach dem anderen abbrennen. Inzwischen scheint der Punkt ohne Rückkehr überschritten.
  • Bun ist faktisch tot.
    Anthropic hat Bun in einem etwas törichten Versuch gekauft, ihre eigenen „Performance“-Probleme zu lösen. Offenbar war ihnen nicht klar, dass von Anfang an miserabler Code das Problem war.
    Andererseits haben sie sich tatsächlich fähige Entwickler ins Haus geholt, und das hat vielleicht in gewissem Maß geholfen.
    Dabei hat sich Bun aber von einem öffentlichen Projekt zu etwas entwickelt, das eher wie ein internes Tool von Anthropic wirkt, und steht jetzt unter AI-Finanzierung ziemlich unter Watte, während der Fokus weitgehend verloren geht.
    Ich hoffe, dass beim Platzen der Blase wenigstens ein Teil der Arbeit an Bun gerettet werden kann. Ich glaube nicht, dass Anthropic es langfristig pflegen wird. Sie verkaufen keinen Runtime-Support und haben auch nicht die Größenordnung von Google, um nebenbei noch eine Runtime zu warten.

• Wenn man den AI-Aspekt kurz ausblendet, halte ich das für eine gute Veränderung.
  Bun hatte mit Zig extrem viele Abstürze und Speicherfehler, anders als Deno auf Rust-Basis.
  Wenn der Rust-Port von Bun natürlich viel unsafe enthält, wird das nicht magisch alles lösen, aber trotzdem dürfte es besser werden.

  • Gibt es Statistiken oder Quellen dafür, dass Bun extrem viele Abstürze und Speicherfehler hatte? Ich sage nicht, dass das falsch ist.
    Dass unschöne Teile in unsafe sichtbarer werden und dadurch Refactoring anstoßen, scheint mir allerdings nicht nur eine Sprachfrage zu sein; Bun hat sich das in gewissem Maß selbst eingebrockt.
  • Behauptest du damit, dass Zig dazu führt, dass man „extrem viele Abstürze und Speicherfehler“ hat?
    Würde das nicht bedeuten, dass es praktisch unmöglich ist, mit so einem Werkzeug hochwertige Software zu bauen? Es gibt ja viele hochwertige Dinge in C/C++; ich frage mich also, was Zig hier falsch macht.
  • Durch die explizite Kennzeichnung mit unsafe ist es leichter zu finden, und es entsteht ganz natürlich eine Liste von Problemen, die gelöst werden müssen.

• Dafür wurden 6 Tage gebraucht. Selbst wenn am Ende nichts Dauerhaftes daraus wird, zeigt das, wie Token und Arbeitsmenge heute und in Zukunft zusammenhängen.
  Es wird schwerer werden, mit Einzelpersonen oder Firmen zu konkurrieren, die mehr Compute haben. Die können dann einfach Dinge tun, die ich nicht kann.

  • Das Übersetzen eines Projekts mit guter Testsuite von einer Sprache in eine andere gilt als klassischer Fall, den Large Language Models gut beherrschen.
    Wenn man eine fertige Codebasis als Beispiel hat und mit einer Testsuite verifizieren kann, ist es viel leichter, iterativ auf ein Ziel hinzuarbeiten. Das Modell sieht dann bereits, was das Ziel ist und wie eine Umsetzung einmal ausgesehen hat; das ist ein deutlich einfacheres Problem, als mit einer Spezifikation bei null zu beginnen.
  • Dasselbe hätte man auch über Dampfkraft oder Elektrizität sagen können. Das ist nicht nur eine einfache Analogie. Der Zauber solcher Dinge liegt darin, dass sie allgemeine Informationsmaschinen sind.
    Man steckt Kapital in gut verstandene, skalierbare Verfahren, schließt Strom an, und Wert kommt heraus.
    Der Punkt ist: In der modernen Welt ist Elektrizität nicht so gelaufen, und deshalb ist es unwahrscheinlich, dass es hier einfach in „die Haben und die Nicht-Haben“ zerfällt.
  • Ich bin mir da nicht sicher. Wirklich gute Produkte entstehen meist dadurch, dass sie ein oder zwei Dinge sehr gut tun, nicht dadurch, dass sie vieles tun.
    Was ich bislang sehe, ist eher: „Wow, jetzt bin ich ein 10x-Engineer!“, also mehr Code-Ausstoß ohne klare Richtung oder Geschmack. Ein Großteil der heutigen LLM-basierten Arbeit wirkt auf mich einfach wie Rauschen.
  • Nein. Solche Agenten werden lokal immer einfacher zu betreiben.
    Ich weiß nicht, ob du Qwen 3.6 27b ausprobiert hast, aber gemessen an seiner Größe ist es absurd leistungsfähig. Wenn man den Kontext gut verwaltet, ist bei kleinen Projekten sogar 100 % Vibe Coding möglich.
    Auch diese Modelle werden wie Compute letztlich über den Preis in Konkurrenz geraten und billiger werden.
  • Mich würde interessieren, was das ungefähr in Dollar gekostet hätte, wenn man nach dem Standardtarif von Anthropic gezahlt hätte. Kann das jemand grob schätzen?

• Viele nehmen das einfach so hin, aber ein erheblicher Teil davon war nur möglich dank einer ungewöhnlich breiten und umfassenden Testsuite, die schon vorher aufgebaut worden war.

  • Trotzdem ist es beeindruckend, weil selbst die fähigsten Engineers dafür viel länger gebraucht hätten.
    Wenn man das später vermarktet, wäre es gut dazuzuschreiben, wie viel menschliche Arbeit in das Entwerfen und Kuratieren der Testsuite geflossen ist, die dieses Tempo überhaupt ermöglicht hat.
    Testsuiten funktionieren für die aktuelle Generation von Large Language Models fast wie eine ideale Umgebung. Eine ausreichend umfassende Testsuite wird zu einer Spezifikation, gegen die ein Agent auf die gewünschte Weise implementieren kann – hier eben in Rust.
    Bei einem Projekt mit so gut gebauten Tests wie Bun könnte ich mir vorstellen, dass man unter Umständen sogar den gesamten eigentlichen Source Code wegwerfen und nur mit Zugriff auf die Tests alles von Grund auf neu implementieren könnte.
  • Wenn diese Testsuite so weit über dem Standard anderer Projekte liegt, dass sie diese Arbeit erst einzigartig möglich macht, wie passt das dann zu der Behauptung, Bun sei instabiler als andere Zig-Programme und müsse deshalb neu geschrieben werden? Wenn ein Teil der Verantwortung auch bei der Testsuite liegt, frage ich mich, was das für den Rust-Port bedeutet.
  • Wir sollen also nur sehen, dass das in 6 Tagen möglich war
    und die Hunderttausenden Stunden ignorieren, die in die ursprüngliche Architektur und Testsuite geflossen sind, die das überhaupt erst ermöglicht haben?

• Das taugt als warnendes Beispiel für AI-gestützte Rust-Portierungen.
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Dass Tests bestehen, bedeutet nicht automatisch, dass etwas wirklich funktioniert.
    Ein Claude-code-C-Compiler bestand 100 % der gcc-Tests, konnte aber nicht einmal hello world ausführen.
  • Die Lehre aus diesen Beispielen ist etwas anders. Large Language Models bauen nach dem, was man ihnen im Feedback-Loop vorgibt.
    Wenn man nur Logiktests liefert, berücksichtigen sie Geschwindigkeit überhaupt nicht. Wenn man Tests einschließt, die Geschwindigkeit messen, und verlangt, die Performance zu treffen, dann tun sie auch das.
    Das ist dieselbe Klasse von Fehlern wie andere LLM-Fehler auch. Es fehlt gesunder Menschenverstand und Kontext für die Dinge, die Menschen wichtig sind. Wenn man Grenzen nicht erzwingt, werden sie ignoriert.
  • Falls es interessiert: Das wurde hier diskutiert: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - März 2026, 422 Kommentare

• Was für eine wilde Zeit, um am Leben zu sein.
  Die grundlegende Dynamik der Branche und des Berufs hat sich in so kurzer Zeit, praktisch über Nacht, verändert.
  An manchen Tagen begeistert mich, wie viel ich jetzt tun kann. Fast alles, was ich will, lässt sich nahezu sofort bauen, und 100 % dessen, wovon ich in Software geträumt habe, könnten Realität werden.
  An anderen Tagen habe ich Angst davor, was mit dem Arbeitsmarkt passiert.
  Plötzlich kann man mit sehr wenig sehr viel erreichen, und die Menge an Software, die die Welt braucht, ist nicht unendlich.
  Werden alle Unternehmen scheitern, deren Kerngeschäftsmodell der Verkauf von Software ist?
  Was passiert, wenn nur bestimmte Unternehmen oder Regierungen Zugang zu den besten Modellen haben?

  • Denk an ein Softwaregeschäft wie Ticketing-Systeme.
    Können 100 Unternehmen mit je 1 Milliarde Token ein besseres Produkt bauen als ein spezialisierter Anbieter mit 100 Milliarden Token?
    Softwareanbieter und SaaS wie ein „Logo-Generator“ sind zwar wohl schon tot, aber solange nicht die nächste Generation von Large Language Models ein Ticketing-System direkt eingebaut hat, werden Ticketing-Anbieter vermutlich okay sein. Weniger Personal vielleicht, aber sicher ist das nicht.
  • Auch rund um den Dotcom-Crash wurde in der Softwarebranche ziemlich oft gesagt, sie sei „zu gesättigt“ und Studierende sowie Jobsuchende sollten lieber fernbleiben.
    Die Erzählung war, dass es im Verhältnis zum Andrang nicht genug Arbeit zu verteilen gebe, und der Crash habe das noch verstärkt.
    Aber selbst als Student konnte man erkennen, dass der Geltungsbereich von Software praktisch unendlich ist. Fast jede kognitive Arbeit, die wir manuell tun, lässt sich durch Software erledigen. Einmal wollte ich anfangen, diese Dinge aufzuzählen, und merkte schnell, dass es einfach unfassbar viel ist.
    Außerdem wurde mir klar, dass mit jeder neuen Art, Dinge zu erledigen, noch mehr Aufgaben auftauchen, die wir uns vorher gar nicht vorstellen konnten. Die Möglichkeiten waren zahllos, und die Erzählung von der „Sättigung“ war offensichtlich ein Mangel an Vorstellungskraft und Verständnis dafür, was Software eigentlich ist.
    Deshalb wusste ich, dass dieses Feld nie gesättigt sein würde. Es war unmöglich, dass uns die Dinge ausgehen, die man in Software abbilden kann.
    Heute fühlt es sich jedoch anders an. Natürlich werden wir auch künftig neue Software bauen, aber inzwischen frage ich mich, ob wir Software irgendwann schneller schreiben können, als wir uns neue Dinge ausdenken, die sie tun soll.
  • Unternehmen und Regierungen werden Zugang zu besseren Modellen haben als die breite Öffentlichkeit. Mythos ist dafür schon jetzt ein Beispiel.
    Die Öffentlichkeit wird sich immerhin mit Modellen helfen können, die hinter der absoluten Spitze zurückliegen.

• Zumindest dabei zuzusehen, wie so ein Versuch läuft, ist interessant.
  Was mich zuerst interessiert, ist, wie umfassend und gut die Testsuite überhaupt ist. Das soll kein Nörgeln sein, aber ich frage mich, wie sicher das Bun-Team sich bei einer Migration fühlen könnte, selbst wenn auf allen Plattformen 100 % erreicht würden.

• Nach der Ubuntu-coreutils-Sache letzte Woche hat sich mein Eindruck von einem Rust-Rewrite mit 99,8 % Testkompatibilität massiv verschlechtert.
  Als ich auf den hier verlinkten Tweet geklickt habe, lief es mir kalt den Rücken hinunter, und inzwischen löst so etwas bei mir eher das genaue Gegenteil aus. Fast so, als würde ich den Ausgang suchen.