Am 15. Juli 2026 veröffentlichte Richard Feldman, der Schöpfer der Programmiersprache Roc, einen Technik-Blog und kündigte an: Sie hätten in 487 Tagen 300.000 Zeilen Rust-Code nach Zig neu geschrieben. Die inkrementelle Build-Zeit des Compilers sank von 3,4 Sekunden auf 35 Millisekunden — exakt 100-mal schneller.
Das ist kein Einzelfall. Bereits zuvor war der Compiler der Sprache Gleam denselben Weg gegangen: von Rust zu Zig. Auf der anderen Seite vollzog die Bun-Laufzeitumgebung Anfang 2026 die Umkehrung — von Zig zu Rust, und das in nur 11 Tagen.
Zwei Spitzenteams von Compiler-Entwicklern trafen in entgegengesetzte Richtungen diametral entgegengesetzte Entscheidungen. Wenn bei einer Sache beide Seiten mit echtem Code gestimmt haben, weiß man: Dahinter steht ein Abwägungs-Problem.
Was bedeuten eigentlich 35 Millisekunden?
3,4 Sekunden sind schon schnell. Der Autor hat selbst einige Projekte in Rust geschrieben, cargo check läuft zwei, drei Sekunden, rust-analyzer brummt im Hintergrund — ehrlich gesagt, man gewöhnt sich daran. Rusts Kompiliergeschwindigkeit hat sich in den letzten 18 Monaten gewaltig verbessert; Rust 1.97 hat gegenüber 1.85 die inkrementelle Build-Zeit um zwei Drittel gekürzt. Feldman selbst lobt in seinem Artikel aufrichtig die Anstrengung des Rust-Teams.
Aber 35 Millisekunden sind eine andere Spezies.
35 Millisekunden bedeuten: In dem Moment, in dem du Strg+S drückst — der Finger noch auf der Tastatur —, hat dir der Compiler bereits das Ergebnis geliefert. Das ist das Verschwinden der Feedback-Schleife. Ein Zig-Teammitglied namens mlugg beschrieb dieses Erlebnis auf Lobsters mit einem Detail: Jeder seiner inkrementellen Builds dauere nur etwa 30 Millisekunden, wovon der Linker lediglich rund 1 Millisekunde beanspruche. Denn Zigs neuer ELF-Linker ist so konzipiert, dass er inkrementell auf Funktionsebene linkt — ändert man eine Funktion, erzeugt der Compiler neuen Maschinencode, und der Linker überschreibt den alten Code direkt im .text-Segment der Ausgabedatei. Kein Syscall, weil die Ausgabedatei via mmap im Speicher liegt.
Dieses „Null-Warten“ verändert das Verhältnis zwischen Entwickler und Compiler. Man muss nicht mehr eine Ladung Änderungen sammeln, um einmal zu bauen, sondern kann rasch zwischen Änderung und Rückmeldung hin- und herprobieren — eine kompilierte Sprache wie eine interpretierte nutzen. Die neue Roc-Compiler-Version unterstützt sogar Hot-Code-Loading: Ein laufender Server kann ohne Neustart des Prozesses auf den geänderten Code umschalten. In der Python-Welt Standard, in der Welt kompilierter Sprachen ein Luxus.
Wofür ist Rusts Typsicherheit eigentlich „teuer“?
Wenn 35 Millisekunden der Köder von Zig sind, wie teuer ist dann die „Sicherheitssteuer“, die Rust erhebt? Wir müssen die Frage zerlegen.
Die erste Rechnung: Kompilierzeit. Rusts Borrow-Checker leistet zur Compile-Zeit etwas äußerst Aufwendiges — er beweist, dass dein Programm keinen Use-After-Free, keinen Double-Free, keine Data Races hat. Dieser Beweis muss den Referenzgraphen des gesamten Programms durchlaufen, mit überlinearer Komplexität im Code-Umfang. Rusts inkrementelle Kompilierung verbessert sich ständig, doch die Natur des Borrow-Checkers schließt ein „sofort fertig“ wie bei Zig aus.
Die zweite Rechnung: architektonische Freiheit. Der Roc-Compiler nutzt umfangreich Arena-Allokatoren und Struct-of-Arrays-Layouts — alle Datenstrukturen verwenden 32-Bit-Indizes statt Pointer und sind nach Feldern in eigenständige Arrays aufgeteilt. Dieser Stil läuft auf modernen CPUs sehr schnell und lässt sich direkt via mmap auf die Festplatte legen, um „Null-Parsing-Deserialisierung“ zu erreichen — beim zweiten Lauf von roc check springen alle bereits geparsten Datenstrukturen vom Datenträger direkt in den Speicher, nahe an memcpy.
Das Problem: Dieser Programmierstil liegt fast unweigerlich mit Rusts Borrow-Checker im Streit. Arena-plus-Index umgeht das Ownership-System, was bedeutet, dass dein unsafe-Anteil den typischen Rust-Projekten weit voraus liegt. Feldmans Team hatte in 300.000 Zeilen Rust etwa 1.200 Stellen mit unsafe — das ist eine Größenordnung höher als die unsafe-Dichte von rustc selbst. Wenn unsafe vom „wenigen zu prüfenden Eckchen“ zum „allgegenwärtigen Normalfall“ wird, schwindet das Sicherheitsgefühl, das der Borrow-Checker vermittelt.
Beide Bücher: Zahlen lügen — und sagen die Wahrheit
Feldman tat etwas Ehrliches: Er zählte die Speicherverfälschungs-Bugs beider Compiler-Versionen.
Rust-Version: 21. Zig-Version: 10.
Auf den ersten Blick gewinnt Zig. Doch beim Zerlegen zeigt sich: Alle 21 Speicherverfälschungs-Bugs der Rust-Version waren Miscompilation (der Compiler erzeugte falschen Maschinencode), keiner im eigenen Logik des Compilers. Der Borrow-Checker tat, was er tun sollte. Von Zigs 10 waren 8 ebenfalls Miscompilation, die verbleibenden 2 Use-After-Free — beide an der Stelle, wo Fehlermeldungen Dateinamen rendern, mit dem Symptom, dass die Dateinamen in der Fehlermeldung zu Kauderwelsch wurden.
Feldmans Fazit ist bemerkenswert ruhig: „Blicke ich auf 18 Monate Entwicklung, hunderte Bug-Reports, hunderttausende Zeilen zurück, ist mein Hauptgefühl: Es macht keinen Unterschied, welche man wählt.“ Jene 2 Use-After-Free hätte Rusts Borrow-Checker zur Compile-Zeit abgefangen, Zigs ReleaseSafe-Modus würde zur Laufzeit panicken — aber die tatsächliche Auswirkung aller drei Varianten war „zwei Bug-Reports: manche Fehlermeldungen zeigen keinen Dateinamen“.
Dieses Fazit bildet einen feinen Kontrast zum Bun-Team. Bun betonte beim Wechsel von Zig zu Rust, dass Use-After-Free bei Projekten, die gleichzeitig GC-Werte von JavaScript und manuell verwalteten Speicher handhaben müssen, eine „Quelle von Unmengen an Bugs“ sei. Feldman stimmt dem voll zu — weist dann aber darauf hin, dass Roc-Compiler keinen JavaScript-Interop benötigt.
Entscheidend ist nicht, wer recht hat. Entscheidend ist: Der Kontext entscheidet alles.
Der Riss in der Community: Das ist kein Heiliger Krieg
Dieser Artikel erreichte auf Lobsters 175 Punkte und 62 Kommentare und löste auch auf Hacker News eine hitzige Debatte aus. Doch das Wichtigste ist: Beide Seiten brachten aus der Praxis stammende, fundierte Argumente.
Rust-Core-Teammitglied Ralf Jung wies auf ein Problem mit der von Feldman zitierten Zahl „rustc hat 40.000 unsafe“-Daten hin — diese Zahl umfasst Standardbibliothek, Tests und Kommentare; der tatsächliche unsafe-Anteil im Compiler ist weit geringer. Er räumte zugleich ein: „Ich stimme voll zu, dass unsafe Rust schwer richtig zu schreiben ist, das ist ein Problem, um das ich mich sehr sorge.“
llogiq — Autor des compact_arena-Crates — wies darauf hin, dass Rusts Typ-Tag-System zur Compile-Zeit Indizes verschiedener Arenen unterscheiden kann und so das Problem „falsche Arrays“ vermeidet. Aber auch er räumte ein, dass diese Technik in Szenarien versagt, in denen die Zahl der Arenen zur Compile-Zeit unbekannt ist.
aapoalas — ein Selbstbezeichner als „Datenorientierungs-Enthusiast“ und Heavy-Rust-Nutzer — brachte die typische widersprüchliche Haltung zum Ausdruck: „Als Datenorientierungs-Enthusiast und Heavy-Rust-Nutzer ist es traurig, ein gleichgesinntes Projekt Rust verlassen zu sehen.“ Er zählte darauf eine Reihe eigener Optimierungsversuche in Rust auf, mit dem Ton einer „widerwilligen“ Ehrlichkeit.
Der Autor findet das Gesunde an dieser Debatte darin: Niemand nennt den anderen einen Narren. Niemand sagt „Rust zu wählen heißt, Performance nicht zu verstehen“ oder „Zig zu wählen heißt, Sicherheit egal zu sein“. Alle räumen ein, dass es eine echte Abwägung ist — und treffen dann, basierend auf dem je eigenen Projektkontext, unterschiedliche Entscheidungen.
Die tiefere Auseinandersetzung: comptime gegen proc macro
Hinter dem Zahlenspiel der Kompilierungsgeschwindigkeit steht ein aufschlussreicherer philosophischer Dissens: Wie treibt man Compile-Zeit-Metaprogrammierung?
Zigs Wahl ist comptime — du schreibst gewöhnlichen Zig-Code, markierst ihn nur für die Ausführung zur Compile-Zeit. Es gleicht einem in den Compiler eingebetteten Interpreter, der generische Programmierung, Code-Generierung und Typ-Manipulation so natürlich macht wie das Schreiben von Laufzeitcode. Keine zweite Syntax, kein Token-Tree, keine Macken der hygienischen Makros.
Rusts Wahl sind proc macros — ein eigenständiges, zur Compile-Zeit laufendes Rust-Programm, das einen Token-Strom nimmt, manipuliert und einen Token-Strom ausgibt. Es ist extrem mächtig (theoretisch kannst du alles tun), aber auch extrem schwerfällig. Jede proc macro ist ein eigenes Crate, dessen Kompilierung allein Zeit kostet. Zigs comptime ist in denselben Compile-Prozess eingebettet, mit fast keinem Zusatzaufwand.
Das ist der versteckte Grund, warum Zig so schnell kompiliert: Es muss nicht erst ein Makrosystem kompilieren und dann deinen Code. Metaprogrammierung und Hauptprogramm teilen sich dieselbe Compiler-Pipeline. Feldman schreibt in seinem Artikel: „Ich mag, dass Zig keine Makros hat.“ — für sich allein klingt das wie ein Seitenhieb, aber im Kontext drückt es eine Ästhetik der Subtraktion aus: eine Mechanik weniger, eine Abstraktion weniger, eine Kompilierlast weniger.
Subtraktion bedeutet natürlich auch Verlust. Feldman räumt ein, dass er Rusts Trait-System und private Felder vermisst. Das sind Ausdruckskraft, die Rust durch Addition gewann. Zig zu wählen heißt, zu akzeptieren, dass „Einfachheit“ wichtiger ist als „Ausdruckskraft“ — zumindest für jene Projekte, denen die Kompilierungsgeschwindigkeit am Lebensfaden hängt.
Das Urteil des Autors: Fisch und Bär, aber du kannst den Teller wählen
Dies ist kein Artikel, der Partei ergreift. Das echte Gefühl des Autors nach obiger Analyse: Das Verhältnis von Rust und Zig wandelt sich von „wer ist besser“ zu „wer ist wofür besser“.
Wenn dein Projekt einer Web-Server oder Datenbank gleicht — relativ stabile Struktur, unsafe auf wenige Hotspots konzentriert, du brauchst eher das langfristige Vertrauen des Borrow-Checkers — bleibt Rust die derzeit sicherste Wahl.
Wenn dein Projekt einem Compiler gleicht — Code, der häufig iteriert und refactored wird, unsafe überall verstreut, Kompilierungsgeschwindigkeit beeinflusst direkt dein Denktempo — wird Zig zu einer nicht mehr zu ignorierenden Option. Denn in solchen Szenarien ist die Sicherheit anders bepreist.
Das Roc-Team hat neu definiert, welche Sicherheitstypen es braucht. Ihre Speichersicherheitsprobleme lagen vor allem im erzeugten Maschinencode, nicht im Compiler selbst — und jenen erreicht der Borrow-Checker gar nicht. Wenn der Engpass der Sicherheit nicht im Rahmen liegt, den die Sprache gewährt, wird die Bezahlung mit Kompilierzeit verhandelbar.
Der Abstand von 35 Millisekunden zu 3,4 Sekunden ist im Kern die Verkörperung zweier Entwicklungsphilosophien: eine, die glaubt, die Maschine könne zur Compile-Zeit alles beweisen; eine, die glaubt, der Entwickler könne zur Laufzeit alles verwalten. Keine ist perfekt — aber zumindest jetzt haben Entwickler wirklich unterschiedliche Optionen.
Das könnte die beste Nachricht der Systemprogrammierung der jüngeren Zeit sein.
Referenzen:
- Richard Feldman: How Our Rust-to-Zig Rewrite is Going (15. Juli 2026)
- Lobsters-Diskussion: How Our Rust-to-Zig Rewrite is Going (175 Punkte / 62 Kommentare)
- Bun-Team: Why We’re Rewriting Bun from Zig to Rust (2026)
- Zig offizielles Entwickler-Log: Incremental Compilation Demo
- Gleam-Sprach-FAQ: Why Rust for the compiler?
