Im Debug-Modus ist nun standardmäßig das selbst gehostete x86-Backend aktiv

• Für x86_64-Targets wird nun Zigs eigenes x86-Backend im Debug-Modus standardmäßig verwendet
• Es besteht mehr Verhaltenstests und erreicht schnellere Kompilierungszeiten als die bisherige LLVM-basierte Lösung
• Durch die Einführung des eigenen Backends wurden Zigs Kompilierungszeiten deutlich verkürzt und die Effizienz bei einigen Aufgaben erhöht
• Zudem wurden mehrere Bereiche ausgebaut, darunter ein verbessertes Build-System, erweiterte Unterstützung für BSD-basierte Betriebssysteme und Verbesserungen an der UBSan-Runtime
• Mit Optimierungen an der Standardbibliothek und an eigenen Tools unterstreicht Zig seine besondere Wettbewerbsfähigkeit

---

Zusammenfassung der neuesten wichtigen Meldungen

8. Juni 2025 – Selbst gehostetes x86-Backend wird im Debug-Modus zum Standard

• Für x86_64-Targets wird jetzt standardmäßig Zigs eigenes x86-Backend verwendet
  • Zuvor wurde LLVM genutzt, um Bitcode in Objektdateien umzuwandeln
  • Unter Windows ist für den COFF-Linker noch zusätzliche Arbeit nötig, daher wurde die Umstellung dort verschoben
• Zigs x86-Backend besteht 1.987 Verhaltenstests und zeigt damit eine höhere Stabilität als das LLVM-Backend (1.980)
  • Insgesamt gibt es 2.084 Tests, einige überschneiden sich jedoch mit LLVM-eigenen Tests und werden daher nur zusätzlich beim Testen des eigenen Backends geprüft
• Der Hauptgrund, warum Zig auf die Entwicklung eines eigenen Codegenerators setzt, ist, LLVM bei der Build-Geschwindigkeit deutlich zu übertreffen
  • Laut Benchmark liegt die durchschnittliche Build-Zeit von zig build-exe hello.zig -fllvm (mit LLVM) bei 918 ms, das eigene Backend erreicht 275 ms
  • Auch bei Speicherverbrauch, CPU-Zyklen, Befehlsanzahl und Cache-Misses sind deutliche Verbesserungen zu sehen
  • Selbst die Build-Zeit großer Projekte wie des Zig-Compilers selbst wurde von 75 auf 20 Sekunden reduziert
• Künftig sind eine vollständig parallele Codegenerierung, stärkere Linker-Funktionen und die Entwicklung eines aarch64-Backends angekündigt
  • Mit einem neuen Legalize-Pass sollen auch die Arbeiten an aarch64 beschleunigt werden
• Die neuesten Änderungen lassen sich direkt über die aktuellsten Builds des Zig-Master-Branches ausprobieren

6. Juni 2025 – Einführungsvideo zum Build-System

• Ein YouTube-Einführungsvideo für Einsteiger in das Zig-Build-System wurde veröffentlicht
  • Es erklärt die Erstellung von Zig-Modulen und -Paketen sowie deren Import in andere Projekte
  • Weitere Videos zum Build-System sollen als Serie folgen

20. Mai 2025 – Ausbau der Target-Unterstützung für FreeBSD und NetBSD

• Durch die Zusammenführung der Pull Requests #23835 und #23913 können mit zig cc und zig build nun Binärdateien für FreeBSD 14.0.0+ und NetBSD 10.1+ gebaut werden
  • Die Strategie zum Extrahieren von libc- und verwandten Bibliotheksinformationen, die bisher für glibc verwendet wurde, wurde auf BSD-Systeme ausgeweitet
  • Die erzeugten abilists-Dateien werden mit Zig ausgeliefert, sodass bei der Cross-Kompilierung Stub-Bibliotheken erzeugt werden können, die exakt zu den jeweiligen libc-Bibliotheken passen
  • System- und libc-Header werden ebenfalls auf Basis der neuesten OS-Version mitgeliefert
  • OpenBSD, Dragonfly BSD, SerenityOS, Android und Fuchsia sind ebenfalls als unterstützte Ziele vorgesehen

9. April 2025 – Offizielle Zig-Website wird als eigenständiges Zine gebaut

• Die offizielle Zig-Website wird nun als eigenständiges Zine gebaut
  • Sie entwickelte sich vom bisherigen Build-Skript zu einer einzelnen ausführbaren Datei weiter
  • Es wird darauf hingewiesen, dass dies ein guter Zeitpunkt ist, es selbst auszuprobieren

Meldungen zu Releases und Funktionsverbesserungen

• Das Release 0.14.0 soll in Kürze erscheinen, und mehrere bemerkenswerte Verbesserungen sind bereits eingeflossen
• Verbesserungen bei C-Interop und der UBSan(Undefined Behavior Sanitizer)-Runtime ersetzen zuvor unklare SIGILL-Fehler durch konkrete und nützliche Fehlermeldungen
  • Beispiel: Ort und Ursache eines vorzeichenbehafteten Integer-Overflows werden klar angezeigt, was die Effizienz beim Debugging deutlich erhöht
• Verbleibende Einschränkungen von UBSan:
  • Keine Unterstützung für Prüfungen dynamischer Typen und Lebenszyklen im Zusammenhang mit C++-vptr
  • Die genaue Positionsanzeige für Attribute wie assume_aligned und __nonnull ist noch nicht vollständig umgesetzt

7. Februar 2025 – Neuerungen bei Debug Allocator und SmpAllocator

• Der Debug Allocator wurde neu gestaltet und unterstützt nun die Erkennung der Seitengröße zur Laufzeit sowie verschiedene Optimierungen
  • Weniger Memory-Map-Erstellungen, Wegfall unnötiger wiederholter memset-Aufrufe mit 0xaa/0x00, Entfernung von Such- und Trie-Datenstrukturen
  • Metadaten werden inline innerhalb der Seiten gespeichert, wodurch sich Compiler-Fehler und Validierung leichter umsetzen lassen
  • Gegenüber einem herkömmlichen malloc auf C-Basis bietet dies Vorteile bei Lesbarkeit und Wartbarkeit
• Mit der Entwicklung des für gleichzeitige Ausführung optimierten SmpAllocator wurde die Effizienz von Speicherallokationen in Multi-Thread-Umgebungen stark gesteigert
  • Benchmarks im Vergleich mit glibc belegen Geschwindigkeit und Ressourceneffizienz
  • Insgesamt wird dies als wichtiger Wendepunkt bewertet, an dem Zig in der Nutzbarkeit C und libc übertrifft

24. Januar 2025 – Eigene Debugging-Umgebung für Zig

• Jacob entwickelte einen LLDB-Fork für Zig und stärkt damit die Debugging-Unterstützung für das eigene Backend
  • Build- und Nutzungsanleitung für den LLDB-Fork sind in einem Wiki-Dokument verfügbar
  • Entwickler, die Zigs eigenes Backend nutzen, erhalten damit eine präzisere Debugging-Umgebung

Fazit

• Zig treibt weiterhin tiefgreifende Veränderungen voran, mit klarem Fokus auf höhere Leistung, Build-Effizienz und bessere Debugging-Möglichkeiten
• Bei unabhängigen Algorithmen, Compiler sowie Build- und Runtime-Tools baut das Projekt eine klar differenzierte Wettbewerbsfähigkeit auf
• Mit Unterstützung für verschiedene Plattformen wie BSD, verbesserten nutzerorientierten Meldungen und Innovationen im Speichermodell liefert Zig weiterhin Entwicklungen, die für Softwareingenieure in der Praxis tatsächlich nützlich sind

[GN⁺]

Hacker-News-Kommentare

• Soweit ich weiß, arbeitet Zig derzeit täglich an verschiedensten Funktionen, um die Developer Experience zu verbessern. Kürzlich gab es zum Beispiel auch diesen PR. Früher stand bei Zig auch Hot Code Swapping auf dem Entwicklungsplan, und bei diesem Entwicklungstempo würde ich erwarten, dass diese Funktion auf x86_64 vielleicht innerhalb eines Jahres möglich sein wird. Das größte Ärgernis ist für mich persönlich die Geschwindigkeit von comptime. Ich hatte einmal ein Experiment, bei dem ich zur Compile-Zeit ein brainF**-DSL ausgeführt habe, und das war wirklich langsam (aber ein lustiges Experiment). Ich frage mich, wann dieser Teil des Compilers verbessert wird. Auf die neuen Backends bin ich ebenfalls sehr gespannt, und ich würde gern auch mein eigenes URCL-Backend für Zig bauen 😉

  • Was die comptime-Performance angeht, weiß man bereits, was zu tun wäre, und es wurde vor langer Zeit sogar schon ein entsprechender Branch begonnen. Allerdings erfordert das eine Überarbeitung des Semantic-Analysis-Codes in nennenswertem Umfang, daher ist es zwar eine wichtige Aufgabe, konkurriert aber mit anderen Prioritäten

  • Hot Code Swapping könnte für die Spieleentwicklung ein absoluter Gamechanger sein. Dass Zig das grundsätzlich allein per Compiler-Flag unterstützen will, finde ich erstaunlich. Mit clang ist so etwas kaum einmal überhaupt versuchbar

  • Ich habe mir URCL nicht im Detail angesehen, aber das zieht mich direkt in den nächsten Rabbit Hole hinein. Man beginnt sich ein wirklich bizarreres Szenario vorzustellen, in dem ein für Minecraft entwickeltes IR zum tatsächlichen Kompilierungsziel einer Sprache wird

  • Ich frage mich, wie einfach es ist, ein Custom-Backend zu bauen. Ich habe es noch nicht selbst ausprobiert, aber ich würde gern mit einem Backend experimentieren, das AIR entgegennimmt und Berichte zur Speichersicherheit erzeugt (zum Beispiel Prüfungen auf Verwendung undefinierter Werte, Escape des Stack-Pointers, Use-after-free, Double Free, alias xor mut usw.)

  • Ich frage mich, ob langsames comptime wirklich das Problem ist. Ich arbeite an einer JSON-RPC-Bibliothek und nutze comptime auf Compile-Zeit intensiv, um JSON an beliebige Funktionen zu dispatchen. Wegen Zigs starkem statischem Typsystem ist dynamischer Dispatch an Funktionen mit beliebigen Parametern zur Laufzeit nicht möglich, daher blieb mir nur, zur Compile-Zeit ein Mapping der Funktionstypen zu erzeugen. Dabei macht mir Sorgen, dass sich dadurch der Code pro Funktion als comptime-instanziierter Code dupliziert und die Binärgröße zwangsläufig wächst

• Schon allein, dass man diesen Stand erreicht hat, ist eine beeindruckende Leistung. Wie auch im Devlog gesagt wurde, ist das, was noch kommt, noch spannender. Das Konzept, beim Build nur die nötigen Teile des Binaries auszutauschen, wirkt frisch und radikal und ist dank des Zig-Projekts nun ein erreichbares Ziel. Es werden sehr spannende Zeiten

• Es wird erwähnt, dass bei großen Projekten wie dem Zig-Compiler die Build-Zeit von 75 Sekunden auf 20 Sekunden gesunken ist.
  Ich bin sehr gespannt, wie weit sich das noch verbessern lässt. Die Zig-Entwickler wirken auf mich ausgesprochen klug.
  Ich frage mich, wie das Package Management aussieht. Ich wollte früher einmal eine QuickJS-+SDL3-App mit Zig bauen, bin aber an der Komplexität von C++ gescheitert und am Ende zu Rust gewechselt. Ich würde es gern auch mit Zig versuchen

  • Das Package Management von Zig ist im Vergleich zu Rust etwas manueller. Man holt die Package-URL direkt über die CLI und importiert das Modul dann im Build-Skript. Der Vorteil dieses Ansatzes ist, dass sich auch beliebige Archive leicht als Abhängigkeiten verwenden lassen, und viele Zig-Packages für C-Bibliotheken bestehen einfach daraus, unberührte Release-Tarballs direkt im Build-Skript einzubinden. Für Einsteiger kann das allerdings etwas kompliziert sein
    Für SDL3 gibt es sowohl einen nativen Zig-Wrapper (https://github.com/Gota7/zig-sdl3) als auch https://github.com/castholm/SDL, das die C-Bibliothek/API etwas einfacher in Zig überführt
    QuickJS unterstützt nur die C-API (https://github.com/allyourcodebase/quickjs-ng)
    Zig macht die direkte Nutzung von C-Packages sehr einfach, aber da die Typisierung streng ist, braucht man beim Umgang mit APIs eventuell häufig Type Casts

  • Der D-Compiler dmd lässt sich in einem Debug-Build in etwa 18,4 Sekunden selbst kompilieren.
    Mein Prozessor ist ein sehr alter AMD Athlon 64 X2 (4400+), aber das läuft so schnell, dass ich bis heute noch kein Upgrade gemacht habe
    (mit ausführlicher Liste der CPU-Informationen)

  • Ich frage mich, ob es einen Guide gibt, wie man Zig in 20 Sekunden baut, um einen schnellen Development Cycle zu haben. Als ich Zig früher gebaut habe, gab es mehrere Stages, und besonders das Bootstrap über WASM hat wirklich lange gedauert

  • Dass Zig sich selbst in nur 75 Sekunden kompiliert, obwohl LLVM verwendet wird, ist schon extrem beeindruckend

• Ich will Zig überhaupt keine überzogenen Forderungen stellen und weiß natürlich, dass es Open Source ist, aber am meisten interessiert mich ein realistischer Zeitplan für 1.0.
  Zig ist für mich fast die perfekte Verkörperung dessen, was ich mir von einer Low-Level-Sprache wünsche, und ich warte jetzt nur noch auf die Stabilisierung.
  Und ich bewundere Zigs minimalistische Designphilosophie aufrichtig

  • Soweit ich weiß, pinnen reale Projekte wie tigerbeetle normalerweise Release-Versionen fest und verwenden Nightlies nur zu Experimentierzwecken

• Als absoluter Anfänger frage ich mich, welche Vorteile Zig gegenüber anderen Sprachen hat. Ich verstehe es als eine modernere Form von C, aber was genau ist daran „modern“?

  • Ein paar Vorteile, die mir sofort einfallen
    • integriertes Build-System, sodass man nicht mehrere separate Tools und Sprachen zusammenstöpseln muss
    • Slices mit expliziter Länge statt C-Arrays (und damit weniger Buffer-Overflow-Probleme)
    • klarer Optional-Typ, bei dem Null-Pointer nicht standardmäßig erlaubt sind (wenn nötig, ist das im Typ explizit sichtbar)
    • enum, Tagged Unions und erzwungene Exhaustiveness-Prüfung bei switch
    • explizites Error Handling (ein bisschen im Rust-Stil). Wenn eine Funktion Fehler zurückgeben kann, kann der Aufrufer sie nicht ignorieren. Es ist nicht wie in C, wo ein Rückgabewert einfach unbeachtet bleiben kann. Etwas schade ist allerdings, dass es keine Standardsyntax gibt, um Fehler und Daten gleichzeitig zurückzugeben
    • automatische Aufräumarbeiten bei Funktionsrückgabe oder Fehlern über defer- und errdefer-Blöcke
    • Codegenerierung über comptime statt Makros sowie Typ-Reflection (@typeInfo usw.)
    • Allocators werden direkt vom Aufrufer verwaltet (mehr Kontrolle darüber, wo und wie Speicher zugewiesen wird)
    • mit GeneralPurposeAllocator ist es (gerade für Anfänger) etwas leichter, Memory Leaks nachzuverfolgen
      Ich war mit C nie wirklich vertraut und hatte wegen vieler unvernünftiger und unintuitiver Aspekte von C immer das Gefühl einer hohen Einstiegshürde in die Low-Level-Programmierung. Zig ist die erste Sprache, mit der mir Systems Programming wirklich Spaß macht und mich interessiert

• Ich frage mich, ob es einen Guide gibt, wie man Zig in 20 Sekunden bauen kann. Ich würde gern den Development Cycle beschleunigen, aber in meiner Erfahrung dauern stage1/2/3 alle lange, sodass Beiträge nicht leicht waren

• Wenn man in Zig mit zig init ein Hello World baut, kommt man auf 9,3 MB, aber mit dem Flag -Doptimize=ReleaseSmall schrumpft das auf 7,6 KB
  Ein einzelnes Flag macht also einen Unterschied um mehr als den Faktor 1000

  • Tatsächlich entfallen 82 % dieses Unterschieds allein auf Debuginformationen
    -OReleaseSmall -fno-strip ergibt 580 KB, -ODebug -fstrip kommt immer noch auf 1,4 MB
    Mit Zigs x86-Backend bietet ein LLDB-Fork speziell für Zig ein deutlich besseres Debugging-Erlebnis
    Ich weiß gerade nicht mehr genau, ob man die comptime-Logik beim Debuggen inzwischen Schritt für Schritt verfolgen kann, aber das war kürzlich Thema einer Diskussion

• Ich denke, Julia könnte erwägen, Zig als Compiler zu nutzen, um Performance-Vorteile zu erzielen. Ich erinnere mich auch daran, wie Julia-Entwickler bei jedem Release nervös waren, ob es wieder Performance-Regressionen geben würde

  • Julia ist faktisch stark an LLVM gebunden. Viele Teile des Ökosystems hängen von LLVM-Intrinsics, AutoDiff (Enzyme), GPU-Kompilierung usw. ab.
    Der Compiler wird allerdings zunehmend retargetbar, und in diesem Bereich wird aktuell ebenfalls aktiv geforscht.
    In Zukunft könnte man sich durchaus ein Bild vorstellen, in dem Zig für Teile der Sprache ein alternativer Compiler wird

  • Es gibt die Ansicht, dass LLVM selbst Julias Public API ist. Tatsächlich gibt es Makros wie @code_llvm, die das IR direkt anzeigen

  • Um die Compile-Zeit zu senken, würde das sicher helfen, aber auch auf der Julia-Seite gibt es noch viel zu tun
    etwa feingranularere Compile-Caches, Tooling zur Vermeidung von Invalidation, das Entfernen der World-Splitting-Optimierung, mehr Nutzung von Multithreading im Compiler, automatisches AOT-Precompiling für bestimmte Signaturen sowie das lazy Kompilieren bzw. Hot-Swappen von Code

• Das ist ein riesiger Fortschritt für Zig und wird im Vergleich zu Rust wahrscheinlich künftig ein zentrales Unterscheidungsmerkmal sein. Nebenbei: Den Großteil des Rendering-Codes für das Performance-Analyse-Tool habe ich selbst geschrieben, und ich freue mich, dass mein Code online breit genutzt wird
  Link zum Projekt poop

  • In Rust gibt es mit Cranelift einen ähnlichen Versuch
    siehe rustc_codegen_cranelift

• Ich denke, das ist genau eine der Voraussetzungen dafür, async/await in Zig wieder einzuführen
  Siehe auch Zigs offizielles FAQ zu async

  • Dieser Teil ist bereits komplett durchdacht, und in den nächsten 2–3 Monaten dürfte es dazu interessante Updates geben. Im Grunde wird das gesamte I/O neu überarbeitet, fast so, als würde man die Standardbibliothek neu schreiben

  • Laut dem Link sieht es eher so aus, als würde async entweder gar nicht zurückkehren oder zumindest bis 2028 völlig außer Reichweite bleiben