Buz – Bun-Fork mit aktuellem Zig und inkrementellen Builds unter 1 Sekunde

• Buz ist ein früher Fork, der auf dem Commit direkt vor Buns Rust-Neuschreibung basiert und als kompatibler Ersatz auf Basis von aktuellem Zig entwickelt wird
• Der gesamte Build-Graph, einschließlich der vendored JavaScriptCore-Quellen, wurde nach build.zig verlagert; mit kleinen Patches an Zig werden inkrementelle Builds unter 1 Sekunde erreicht
• Tests für neue Features und Bugfixes aus der Rust-Version von Bun wurden übernommen, doch viele Tests schlagen noch fehl; Upstream-Features und Änderungen an JavaScriptCore müssen weiter nachgezogen werden
• Mehr als 11.000 Zeilen ungenutzter Code wurden entfernt; bei der Modernisierung einiger Implementierungen hin zur Zig-Standardbibliothek wurden auch mehrere Bugs behoben
• Noch nicht für den Produktionseinsatz geeignet; langfristiges Ziel ist es, mithilfe von LLMs und menschlicher Aufsicht technische Schulden abzubauen und danach eine auch ohne LLM gut wartbare Codebasis zu schaffen

---

Projektziel und Entwicklungsstand

• Buz ist ein in Entwicklung befindlicher Fork, der auf dem letzten Commit basiert, bevor Bun in Rust neu geschrieben wurde
• Der Fokus liegt darauf, einen mit Bun kompatiblen Ersatz und zugleich eine aufgeräumtere Codebasis zu schaffen
• Die Entwicklung befindet sich in einem sehr frühen Stadium; Buz ist nicht bereit für den Produktionseinsatz
• Buz wurde veröffentlicht, um doppelte Entwicklungsarbeit zu vermeiden, da bereits ein ähnliches Zig-basiertes Bun-Projekt auf Ziggit öffentlich gemacht wurde
  • Zum Zeitpunkt der Veröffentlichung war dieses Projekt noch nicht geprüft worden

Portierung auf aktuelles Zig und inkrementelle Builds

• Bun wurde auf das aktuelle Upstream-Zig portiert; für inkrementelle Rebuilds wurden kleine Patches an Zig angewendet
• Der gesamte Build-Graph, einschließlich der vendored Quellen von JavaScriptCore, wurde in build.zig integriert
• Mit dieser Konfiguration sinkt die Zeit für inkrementelle Builds auf unter 1 Sekunde, wodurch sich Entwicklungszyklen beschleunigen
• Das Projekt enthält ein Zig-master-Submodul mit angewendetem Patch für inkrementelle Builds
• Auch mit dem damaligen Upstream-Zig-Commit 2b1c663 lässt sich das Projekt erfolgreich bauen

Kompatibilitätstests und Upstream-Tracking

• Tests aus der Rust-Version von Bun wurden übernommen, darunter viele Tests zur Verifikation neuer Features und Bugfixes
• Viele Tests bestehen noch nicht, daher muss Buz weiter zum Bun-Upstream aufschließen
• Parallel dazu werden die Funktionskompatibilität gewahrt, der Code aufgeräumt und technische Schulden reduziert
• Auch Änderungen an JavaScriptCore müssen fortlaufend verfolgt werden

Aufräumen und Modernisieren der Codebasis

• Mehr als 11.000 Zeilen Code, der in Bun überhaupt nicht genutzt wurde, wurden entfernt
• Teile des Codes wurden neu geschrieben und modernisiert, mit stärkerer Nutzung der Zig-Standardbibliothek
• Im Zuge des Aufräumens und der Modernisierung wurden außerdem mehrere Bugs behoben
• Die bestehende Bun-Codebasis umfasst rund 600.000 Zeilen; um einen aufgeräumten Zustand zu erreichen, müssten nach Einschätzung des Projekts zahlreiche Subsysteme neu geschrieben werden

LLM-Nutzung und Beitragsrichtlinie

• Um komplexen bestehenden Code aufzuräumen, sollen LLMs umfangreich eingesetzt werden, jedoch zusammen mit menschlicher Aufsicht und besseren Entwicklungspraktiken
• Von Menschen direkt geschriebene Beiträge sollen nicht angenommen werden, bis die Codebasis als ausreichend aufgeräumt gilt
• Priorität haben der Abbau technischer Schulden und idiomatischer Zig-Code; Ziel ist eine Codebasis, die innerhalb von Wochen oder Monaten als kompatibler Ersatz für Rust Bun 1.4.0 veröffentlicht werden kann
• Um Unterstützung von Entwicklern, die Sol oder Fable nutzen können, wird gebeten
• Langfristig soll eine Codebasis entstehen, die auch ohne Hilfe von LLMs leicht wartbar ist; zugleich sollen im Entwicklungsprozess die Zig-Kenntnisse verbessert werden

[GN⁺]

Hacker-News-Meinungen

• Das Interessanteste an diesem Fork ist, dass er bewiesen hat: Auch Bun hätte sich schon längst schnell bauen lassen können.
  Zwar unterstützt Zigs inkrementelle Kompilierung noch kein aarch64, und Binary-Patching ist nur mit dem Linux-Linker möglich, aber die Unterstützung der wichtigsten Plattformen scheint nur eine Frage der Zeit zu sein.
  • Angesichts des Aufruhrs darum, dass der Zig-Compiler geforkt wurde, um die Build-Geschwindigkeit zu erhöhen, ist es überraschend, dass das hier nicht der Top-Kommentar ist.
    Dass ein Ein-Personen-Team Builds in 1 Sekunde erreicht hat, zeigt, dass die langsamen Builds das Ergebnis nachlässiger Entwicklungspraxis waren und dass die Zeit in den Fork zu stecken eine völlig falsche Ressourcenverteilung war.
• Von einem LLM kaputtgemachten Code wieder mit einem LLM aufzuräumen – offenbar haben wir 2026 den Gipfel der Technologie erreicht.
  • Menschen haben bisher auch von Menschen kaputtgemachten Code aufgeräumt; logisch widersprüchlich ist das also nicht.
  • Die Ergebnisse eines LLM sind nur so gut wie die Kompetenz des Nutzers, der es anweist.
  • Ich bin AI gegenüber skeptisch, aber bereit, sie zu nutzen; wenn ein LLM seine eigenen Ergebnisse wirklich selbst aufräumen kann, wäre das ein Gamechanger.
  • Ich dachte ähnlich, aber direkt danach heißt es, dass Menschen die Kontrolle übernehmen, technische Schulden abbauen und idiomatischen Zig-Code schreiben wollen, um innerhalb von Wochen oder Monaten eine Codebasis zu schaffen, die Rust Bun 1.4.0 ersetzen kann.
    Letztlich klingt das danach, mehr oder besser anweisen zu wollen. Codestruktur scheint auch Geschmackssache zu sein; gestern hatte ich ein absurdes Gespräch mit einem Freund, der darauf beharrte, dass man vier Backend-Prozesse brauche, um eine einzige HTTP-Anfrage zu verarbeiten.
  • Von Anfang an lief es in diese Richtung. Kaputte LLM-Ausgaben, die nur wie Software aussehen, aber von Menschen nicht gelesen oder verstanden werden können, werden zu Code; am Ende wird also aller Code zwangsläufig dafür gemacht sein, von Maschinen gelesen und geschrieben zu werden.
    Ich sehe die Phase, in der Menschen eingreifen, von Anfang an als Übergangsphase.
• Erstaunlich, dass sie aus Bun 11.000 Zeilen komplett toten Code entfernt, die Nutzung der Standardbibliothek modernisiert und dabei auch noch zahllose Bugs behoben haben.
  Ich frage mich, ob das in großen Projekten üblich ist und ich es nur nicht wusste.
  • Insgesamt sind es 600.000 Zeilen, also macht der tote Code etwa 1,8 % aus. Je größer die Codebasis, desto breiter muss man schauen, um zu beurteilen, ob Code tatsächlich nicht genutzt wird; außerdem können weit entfernte Änderungen im Lauf der Zeit toten Code erzeugen, was es häufiger macht.
    Unklar ist, ob es offensichtlicher Code wie if (false) { dead_code(); } ist oder Code, der über dynamisches Dispatching möglich wäre, logisch aber nie aufgerufen werden kann. Im ersten Fall wären 1,8 % viel, im zweiten vielleicht wenig; in vielen Projekten sammelt sich hinter alten Feature-Flags Code an, der praktisch nie wieder ausgeführt wird.
    Kleine Mengen toten Codes, etwa einfache Utilities oder generierter Code, kann man stehen lassen; manchmal führt das Entfernen aber zu Ketten aus Löschungen und Vereinfachungen.
  • In einer früheren Firma habe ich eine 10.000-Zeilen-Komponente auf 2.000 Zeilen reduziert und dabei alle wichtigen Bugs behoben.
    Streng genommen war das kein toter Code, aber wenn man eine kleine falsche Abstraktion bereinigt, öffnen sich nacheinander weitere Aufräummöglichkeiten, und am Ende bleibt Software übrig, die nur noch das tut, was sie soll. Codebasen blähen sich mit der Zeit auf; bei Buns Größe finde ich eher überraschend, dass nur 11.000 Zeilen gefunden wurden.
  • Der Zig-Compiler kompiliert lazy, erkennt also keine toten Funktionen, die von keiner kompilierten Funktion aufgerufen werden.
  • Gemessen an Buns Entwicklungsweise ist das weniger als erwartet; in der Codebasis dürfte noch viel mehr übrig sein.
  • Überraschend ist eher, dass einen diese Menge toten Codes in einer großen Codebasis überrascht. Das sind nur etwa zehn normal große PRs.
• Ich frage mich, wie lange du schon programmierst, wenn du 11.000 Zeilen toten Code für so ungewöhnlich hältst.
  • Mehr als zehn Jahre. Ich meinte offensichtlich toten Code, der von nirgendwo aufgerufen wird, und fragte mich, ob es andere Projekte mit so viel davon gibt.
• Bei jedem agentengetriebenen Coding-Projekt zeigte sich ein Tick-Tock-Pendel zwischen Feature-Entwicklung und Codepflege.
  In der Tick-Phase fügt man schnell Features hinzu und erzeugt eine korrekte, aber extrem unordentliche Version; in der Tock-Phase verdaut und bereinigt man das Ergebnis und verbessert Performance, Wartbarkeit und Änderungsrobustheit.
  Man baut an einem Tag per Vibe Coding eine funktionierende App und verbringt dann eine Woche damit, daraus ein Projekt zu machen, dem man weiter Features hinzufügen kann, ohne dass es wie ein Kartenhaus zusammenfällt. Vor AI war es ähnlich, aber professionelle Entwickler hatten ein stärkeres mentales Modell des Systems und arbeiteten langsamer, sodass der Wechsel nicht so abrupt war.
  • Am Ende muss man den Code selbst durchsehen und prüfen, ob die Logik nicht überall dupliziert ist und tatsächlich wartbar bleibt.
    Coding-Modelle neigen stark dazu, Abkürzungen zu nehmen, die Kapselung brechen, oder Code zu kopieren, der nicht dupliziert werden sollte.
• Ich möchte das auffälliges Performance-Programming nennen. Ich mag Performance, und Build-Zeiten sollten möglichst nahe bei 0 Sekunden liegen, aber inzwischen sind wir im Bereich abnehmender Erträge; der aktuelle Flaschenhals dürfte nicht die Build-Zeit sein.
  • Bun-Entwickler, die inkrementelle Kompilierung nicht nutzen konnten und selbst lange Wartezeiten erlebt haben, würden dem nicht zustimmen: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    In großen Projekten kann man nicht jedes Mal mehrere Minuten warten, wenn man Tests ausführt oder semantische Fehler prüft; Build-Zeit ist eindeutig ein Flaschenhals.
  • Für solche Projekte sind schnelle Builds unverzichtbar und meiner Ansicht nach ein wichtiger Schritt, um Wartung zu erleichtern.
• Ein Bun, das von jemandem gepflegt wird, dem Codequalität wichtig ist, wäre willkommen, aber das ist eine herkulische Aufgabe.
  • Eher als herkulisch ist es eine endlos wiederkehrende Sisyphos-Aufgabe.
• Ich würde auch gern das genaue Gegenteil sehen: einen Zig-Fork, der ausschließlich AI-Beiträge annimmt.
  Nicht weil ich AI besonders stark befürworte, sondern eher als Konzeptkunst oder Experiment; es wäre interessant zu sehen, wie sich die beiden Projekte unterschiedlich entwickeln.
• Das eng verwandte Cruller nutzt ebenfalls die Bun-Codebasis vor der Neuschreibung, konzentriert sich aber nur auf den produktionsrelevanten Runtime-Teil.
  Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  HN-Diskussion: https://news.ycombinator.com/item?id=49017344
• Ich verstehe nicht, warum Bun so viel Aufmerksamkeit bekommt. Warum nicht einfach zu Node + npm + Vitest + Vite zurückgehen?
  • Es gibt das Projekt Nub, das die Vorteile von Bun zu Node bringen will; es kann auch gut zeigen, warum Leute Bun bevorzugen und wo die Lücken der bestehenden Tools liegen.
    https://nubjs.com
  • Genau diese Aufzählung ist der Grund für die Aufmerksamkeit. Statt viele Tools zu kombinieren, kann man eine einzige Runtime verwenden, die alles Nötige erledigt.
    Zweckgebundene Tools zu kombinieren ist nicht per se ein Problem, aber es ist sehr bequem, wenn im Ausgangszustand alle Probleme gelöst sind. Buns Bundler hat auch Runtime-APIs, sodass derselbe Prozess, der Assets ausliefert, direkt im Speicher bundlen kann, ohne mit einem externen Bundler zu koordinieren oder statische Dateien auf die Festplatte zu schreiben.
  • Allein die Tatsache, dass man vier Tools aufzählen muss, zeigt, wie schlecht die bisherige Lage ist.
  • Inzwischen ist auch unklar, warum man weiter npm verwenden sollte.