Buz: ein moderner Fork von Bun in Zig, der in weniger als einer Sekunde neu aufgebaut wird

Nach der Migration von Claude Code zu Bun (mit Rust-Kern) letzte Woche kündigt ein Mitglied der Zig-Community Buz an: ein Fork von Bun, neu geschrieben mit den aktuellen Versionen von Zig, der sub-sekundenschnelle inkrementelle Builds verspricht. 224 Punkte an der Spitze von Hacker News.

Der konkrete Fall

Bun (der JavaScript-Runtime für Node mit gleichzeitiger Ausführung) ist größtenteils in Zig geschrieben, einer Systemsprache, die mit dem Versprechen "das, was C macht, aber besser" überzeugt. Allerdings, je größer Bun wurde, desto mehr steckte es in einer relativ alten Version von Zig fest, mit Compilierzeiten, die explodieren, sobald man auch nur eine Datei ändert.

Dann kam Buz, ein Fork, der von einem Mitglied der Community auf ziggit.dev (dem offiziellen Forum der Zig-Entwickler) am 24. Juli 2026 angekündigt wurde. Die Kernaussage lautet: "drop-in replacement for Bun using modern Zig, with sub-1s incremental builds". Auf Hacker News erreichte die Ankündigung schnell 224 Punkte und 161 Kommentare - für ein neues Projekt ist das ein starkes Signal.

Das kommt zu einem entscheidenden Zeitpunkt für das Bun-Ökosystem: Letzte Woche dokumentierte Simon Willison, dass Claude Code nun Bun (mit einem Rust-Kern) verwendet - ein Zeichen dafür, dass Bun in der KI-Toolchain Fuß fasst. Jede Reibung bei der Beitragsgeschwindigkeit wird daher zu einer Frage, die über das einzelne Projekt hinausgeht.

Was man verstehen muss

Der Name des Projekts, Buz ("Bun" + "Zig"), ist nicht nur ein Wortspiel. Er dokumentiert die technische Wette:

• Die neuesten Versionen von Zig verfolgen (die Sprache ist in der Pre-1.0-Phase, Breaking Changes sind häufig, aber die Compiler-Optimierungen schreiten schnell voran).
• Die Nutzung des selbstgehosteten Compilers von Zig, der echte inkrementelle Builds liefert.
• Die API-Kompatibilität mit Bun, um das Ökosystem nicht zu fragmentieren (wie es Deno vs. Node tut).

Der entscheidende Punkt sind die sub-sekundenschnellen inkrementellen Builds. Wenn man an einem so großen Runtime arbeitet, zählt jeder Zyklus "Ich ändere eine Zeile → Ich teste". Von mehreren Dutzend Sekunden auf weniger als eine Sekunde zu wechseln, verändert die Beitrags-Ergonomie komplett - das ist die Art von Detail, die entscheidet, ob ein Projekt externe Entwickler anzieht oder bei seinem Gründerteam stecken bleibt.

Die echte Debatte

Die Kommentare auf HN sind in zwei Lager gespalten:

1. Die Begeisterten - ein von der Community geführter Fork kann Dinge entsperren, die Jarred Sumner (Gründer von Bun) nie Zeit hatte anzugehen. Bemerkenswertes Vorbild: die Forks von OpenSSL/LibreSSL oder io.js, die Node.js gezwungen hat, sich zu bewegen.
2. Die Skeptiker - das Risiko der Divergenz ist real. Ein "drop-in replacement", der 5 % der APIs verfehlt, schafft am Ende mehr Probleme, als er löst. Und die Wartung eines aktiven Forks eines so großen Projekts wie Bun erfordert viel Personal.

Unsere Analyse

Es ist wahrscheinlich interessanter als Beweis von Konzept denn als ernsthafter Konkurrent zu Bun. Wenn Buz zeigt, dass man sub-sekundenschnelle Builds auf einer Codebasis dieser Größe haben kann, wird das Bun-Team alles daran setzen, die Optimierungen upstream zu bringen - was allen zugutekäme. Das Muster "Fork, der den Originalen zum Handeln zwingt" ist eine Konstante in der Open-Source-Welt.

Zu beobachten: die Häufigkeit der Commits in den kommenden Wochen. Ein Fork, der nach 15 Tagen stirbt, kommt häufig vor; ein Fork, der drei Monate durchhält, beginnt zu zählen.

Zu beachten Buz ist noch kein glaubwürdiger Ersatz für Bun, aber er zeigt ein echtes Problem auf: Die Stagnation der von Bun verwendeten Zig-Version bremst die Geschwindigkeit des Projekts. Ob Buz erfolgreich ist oder nicht, der mechanische Effekt wird sein, Bun zu einer schnelleren Migration zu zwingen - was auch den neuen Positionierung von Bun in der KI-Toolchain (Claude Code) entspricht.