Zurück zu Zig – Zig → Rust → Zig

 (gracefulliberty.com)
4 Punkte von GN⁺ 22 시간 전 | 3 Kommentare | Auf WhatsApp teilen
  • Zig begann als Low-Level-Sprache, die die Unannehmlichkeiten von C reduzieren sollte, und ist mit Philosophien wie expliziter Speicherallokation und keinem versteckten Kontrollfluss wieder eine Sprache, die eine erneute Betrachtung verdient.
  • Rust war eine praktische Alternative, um Zigs häufigen Änderungen und dem unreifen Ökosystem zu entkommen, zeigte aber bei FFI, Cross-Compilation und versteckten Allokationen Grenzen.
  • Die Entscheidung, zu Zig zurückzukehren, hatte nicht nur technische Gründe; auch ein Vertrauensverlust in das Rust-Projekt rund um Governance und Richtlinien zu LLM-generiertem Code spielte eine Rolle.
  • Zig im Jahr 2026 ist weiterhin instabil, und Zig 0.17.0 wird voraussichtlich die Build-Systeme kaputtmachen, aber das Sprachgefühl unterscheidet sich nicht stark von 2020, und die Erfahrung mit Paketverwaltung ist besser geworden.
  • Zig bietet keine Rust-artige Compile-Time-Speichersicherheit, setzt stattdessen aber mit ReleaseSafe, Tests, Fuzzing und einer Assertion-Philosophie auf ein Gleichgewicht aus Einfachheit und Laufzeitsicherheit.

Der Ausgangspunkt der Faszination für Zig

  • Zig begegnete mir erstmals 2020; damals wirkte es wie eine kleine neue Sprache mit Compile-Time Code Execution und einfachen Abstraktionen.
  • Beim Lernen von C gefiel mir das Gefühl, den Computer direkt zu kontrollieren, aber die alten Abstraktionen und die unzureichenden Werkzeuge waren unbequem.
  • Auch wenn Zig neu und instabil war, versprach es eine Ersatzsprache für C, und die Möglichkeit, „die nächste Sprache“ zu lernen, war reizvoll.
  • Andrew Kelleys Software Should Be Perfect prägte den Maßstab dafür, wie man Programmiersprachen und Software betrachtet.
    • Fehlbare explizite Speicherallokation
    • Kein versteckter Kontrollfluss
    • Universelle Wiederverwendbarkeit
  • Beim Schreiben einer Spielzeug-Programmiersprache, eines Literate-Programming-Werkzeugs und eines Webservers in Zig fühlte es sich wie eine Sprache an, die bequemer als C ist, aber weniger Gefahren birgt.

Warum der Wechsel zu Rust erfolgte

  • Zig-Code brach häufig, und als Student fehlte die Zeit, Projekte ständig an die neueste Sprachversion anzupassen.
  • Damals gab es anyzig noch nicht, sodass es schwierig war, auf einem System bequem mit mehreren Zig-Versionen zu arbeiten.
  • Wenn man nach ein paar Monaten zu einem Projekt zurückkehrte, musste man teils große Refactorings vornehmen, die man nicht verstand, nur damit es wieder lief.
  • Auch das Ökosystem war noch klein.
    • Als neuer Programmierer fehlte die Fähigkeit, alles Nötige selbst zu implementieren.
    • Es gab wenige Bibliotheken und Beispiele.
    • Die Standardbibliothek änderte sich ständig.
    • Auch die grundlegende Dokumentation war instabil.
  • Rust war bereits seit Jahren stabilisiert und verfügte über ein starkes Ökosystem.
  • Rust zu lernen war schwierig, aber sobald man es beherrschte, lief der Code stabil, und diese Stabilität war wichtig.
  • Es war eine schnelle Low-Level-Sprache, die die nötige Ausdrucksstärke bot und die Kosten der Instabilität reduzierte, die man bei Zig erlebt hatte.
  • Rust half dabei, ein Speichermodell zu entwickeln, das auch beim Einsatz von Sprachen mit weniger eingebauten Prüfungen nützlich ist.
  • In Code ohne Panic konnte man wiederverwendbaren Code ohne versteckten Kontrollfluss oder Garbage Collector schreiben.
  • Allerdings versteckte Rust Speicherallokationen und erschwerte die Arbeit mit C.

Unzufriedenheit, die Zig wieder interessant machte

  • Rust war nicht die perfekte Sprache, um die gewünschten wiederverwendbaren Programme zu bauen.
    • FFI ist schwierig.
    • Cross-Compilation ist mühsam.
    • Versteckte Speicherallokationen, die als nicht fehlschlagend behandelt werden, sind belastend.
    • Durch die Bindung an LLVM kann es lange dauern oder unmöglich sein, so viele Plattformen wie C zu unterstützen.
  • Auch die Governance blieb ein unangenehmer Punkt.
    • Die Rust Foundation hat mehrere große Unternehmen als foundation members.
    • Wenn die größten Unternehmen der Welt jedes Jahr Hunderttausende Dollar beisteuern, kann das die Entwicklungsrichtung von Rust beeinflussen.
  • Es war schockierend zu sehen, dass in der Open-Source-Community immer mehr Projekte LLM-generierten Code akzeptieren.
  • In mehreren Projekten verfassten oder forderten Maintainer und Nutzer LLM-Richtlinien.
  • Zig hat LLMs im Projekt vollständig verboten.
  • Rust führte eine Umfrage durch, und die allgemeine Stimmung in der Community war LLM-kritisch, doch eine offizielle Richtlinie wurde nicht sofort erstellt.
  • Rusts Richtlinienvorschlag enthielt in PR-Kommentaren eine Klausel, die untersagte, die folgenden Themen anzusprechen:
    • langfristige soziale und wirtschaftliche Auswirkungen von LLMs
    • Umweltauswirkungen von LLMs
    • urheberrechtlicher Status von LLM-Ausgaben
    • moralische Urteile über LLM-Nutzer
  • Diese Klausel wurde nach Gegenreaktionen entfernt, aber schon die Tatsache, dass es sie gab, verringerte das Vertrauen in das Rust-Projekt.
  • Die Richtlinie selbst erschien größtenteils in Ordnung, da sie LLMs einschränkt und Slop reduziert.
  • Diese Erfahrung wurde zum Anlass, Zig nach Jahren wieder ernsthaft zu betrachten.

Zig im Jahr 2026

  • Zig ist weiterhin instabil.
  • Ich wollte mit einem Zig-0.16.0-Beispiel aus dem Web beginnen, doch es war bereits veraltet.
  • Um produktiv mit Zig zu arbeiten, ist es am besten, eine Kopie des Quellcodes der Standardbibliothek griffbereit zu haben und sich mit ihr vertraut zu machen.
  • Zig 0.17.0 soll bald erscheinen und wird die Build-Systeme aller Projekte kaputtmachen.
  • Die Maintainer wollen sich in Richtung Stabilisierung bewegen, und solche Brüche sind Teil dieses Prozesses.
  • Glücklicherweise hat sich die Sprache selbst seit 2020 nicht stark verändert.
    • Die meisten Intuitionen funktionierten weiterhin.
    • Teile der Bibliotheken wurden überarbeitet, aber der Code war gut lesbar.
    • Aktuellen Zig-Code werde man vermutlich auch in sechs Jahren noch wiedererkennen.
  • Zig hat nun einen Paketmanager.
    • Früher musste man für die Dependency-Verwaltung meiner Erinnerung nach git submodule verwenden.
    • Das eingebaute Werkzeug ist viel besser.
    • Projekte können Dependencies über Git und Tarballs definieren.
    • Vendoring funktioniert einfach.
  • Das Ökosystem ist weiterhin nicht riesig, aber ein riesiges Ökosystem war auch nicht das Ziel von Zig.
  • Es gibt kein offizielles Paket-Registry, und man vertritt die Haltung, dass kein weiteres NPM oder crates.io nötig ist.
  • Derzeit scheint Zig ein angemessenes Gleichgewicht gefunden zu haben.

Blick auf Speichersicherheit

  • Zig bietet keine Speichersicherheitsgarantien wie Rust.
  • Das ist ein Trade-off zugunsten von Einfachheit, und die Komplexität von Rusts affinen Typen scheint den Sicherheitsgewinn nicht vollständig wert zu sein.
  • Das bedeutet jedoch nicht, dass Zig Sicherheit aufgibt.
  • Aus der Perspektive von Zig is safer than unsafe Rust kann Zig in Situationen, in denen man unsafe Rust verwenden müsste, die bessere Wahl sein.
  • Zig arbeitet auch daran, die Sprache sicherer zu machen.
    • Der Ansatz konzentriert sich nicht auf unsafe-Code-Bereiche, sondern auf Release-Modi.
    • Derzeit crasht Zigs ReleaseSafe-Modus bei Assertion-Fehlschlägen und initialisiert allen Speicher.
    • Andrew Kelley interessiert sich dafür, etwas wie Fil-C in ReleaseSafe aufzunehmen.
  • Dieser Ansatz bietet nicht die Compile-Time-Speichersicherheit von Rust ohne unsafe, ist aber auch keine Death Spiral, wie manche sagen.
  • Speichersicherheit ist ein Spektrum, und es gibt nicht den einen Ansatz, der in jeder Situation am besten ist.
  • Zigs Ansatz besteht darin, ReleaseSafe zur Laufzeit so sicher wie möglich zu machen und Korrektheit durch Tests und Fuzzing zu überprüfen.
  • Nicht geprüfte illegal behavior muss in diesem Prozess gefunden werden; nachdem Korrektheit nachgewiesen wurde, kann man die Binärdateien anderer Release-Modi sicher ausliefern.
  • Dieser Ansatz hat gegenüber dem Rust-Modell Nachteile, wirkt aber angesichts von Zigs starkem Streben nach Einfachheit nicht grundsätzlich unterlegen.
  • Wenn Compile-Time-Speichersicherheit wichtig genug ist, um die Kosten eines komplexen Typsystems und langer Compile-Zeiten zu tragen, sollte man Rust wählen.
  • Zigs Speichersicherheitsmodell setzt sich auch in der Assertion-Philosophie fort.
    • Statt Assertions in ReleaseFast zu deaktivieren, vertraut man darauf, durch Tests bewiesen zu haben, dass die Assertions korrekt sind und der betreffende Pfad unreachable ist.
    • Dadurch kann Zig den Code optimieren.
    • Ein dazugehöriger Artikel ist your assertions are correct.

Künftige Nutzung

  • Mit der Standardbibliothek und den Release-Änderungsprotokollen in Reichweite bin ich bereit, Softwareprobleme mit Zig anzugehen.
  • Wenn ich mich nicht mit Low-Level-Details beschäftigen möchte, werde ich meine bevorzugte Skriptsprache verwenden.
  • In künftiger Software plane ich, Zig als zentrales Werkzeug einzusetzen.
  • Die Möglichkeit, nicht dauerhaft bei Zig zu bleiben, bleibt offen.
    • Wenn Rusts Stabilität oder Typsystem nötig ist, kann ich Rust verwenden.
    • Meine Meinung zu Zigs Ansatz könnte sich vollständig ändern.
    • Mehrere Sprachen können und sollten koexistieren.
  • Zig steht für eine Software-Vision, die sich auf Nutzer konzentriert, indem sie Softwarequalität nicht ignoriert, sondern annimmt.
  • Menschen verdienen vertrauenswürdige und leistungsfähige Software, und im LLM-Zeitalter wird sorgfältig gebaute Software seltener, während Menschen unter Druck geraten, immer schlechteren Slop zu akzeptieren.

Verwandte Beiträge

3 Kommentare

 
clastneo 16 시간 전

Ich habe beim Lernen von Zig einmal aufgegeben, als ich hörte, dass eine neue Version erscheinen soll.
Wenn eine stabile Version herauskommt, wäre es wohl wieder einen Platz auf meiner Lernliste wert, aber bisher sind die Breaking Changes so massiv, dass ich mich kaum herantraue.
 
click 19 시간 전

Zig ändert ständig die Sprachspezifikation und verwirft dabei immer wieder die Abwärtskompatibilität. So ist es meiner Meinung nach schwierig, es in wichtigen Systemen einzusetzen, zumindest bis Version 1.0 erschienen ist.
Ghostty scheint wegen der Änderungen an std.IO ziemlich zu kämpfen: Issue
Um ein Beispiel aus einer anderen Sprache zu nennen: Wenn in Java nach der Einführung von Future die JDBC-API so geändert worden wäre, dass sie Future oder CompletableFuture zurückgibt, hätte das sicher einen großen Fortschritt bedeutet, aber um den Preis enormer Verwirrung.
 
GN⁺ 22 시간 전
Kommentare auf Lobste.rs

  • Ich möchte Zig irgendwann noch einmal ausprobieren.
    Ich will es wirklich tun, war bisher aber mit anderen Dingen beschäftigt.
    Als ich Zig zuletzt angefasst habe, bin ich nach etwa drei Stunden auf einen Compilerfehler gestoßen, und das ist mir ziemlich im Gedächtnis geblieben. Fairerweise muss man sagen, dass dieser Bug im aktuellen Branch bereits behoben war.

  • Ich habe Zweifel an der Aussage, dass es „sehr lange dauern oder nie passieren wird, so viele Plattformen wie C zu unterstützen, weil man an LLVM gebunden ist“.
    Ich frage mich, welche von LLVM nicht unterstützten Plattformen man als Ziel haben möchte und inwiefern Zig hier besser wäre.
    Soll das heißen, dass Zig tier-4-C-Code erzeugt und GCC diesen dann für hppa, alpha und sh kompilieren kann?

    • Soweit ich es verstanden habe, arbeitet Zig aktiv daran, die Abhängigkeit von LLVM zu reduzieren. Gemeint war wohl eher, dass man künftig beim Implementieren neuer Targets im Zig-Compiler nicht unbedingt das LLVM-Projekt selbst anfassen muss.
    • Derzeit ist C-Codegenerierung die Art, wie das umgesetzt wird.
      Das Problem ist, dass Zig offizielle Backends außerhalb von LLVM hat, Rust dagegen LLVM verwendet.
      Eine Systemprogrammiersprache, die maximale Wiederverwendbarkeit von Software anstrebt, sollte auf möglichst vielen Systemen laufen; besonders dann, wenn sie wie Zig C ersetzen will.
    • Meiner vagen Erinnerung nach lag der Schwerpunkt der Bedenken eher bei den Kompilierzeiten als bei der Plattformunterstützung.

  • Nach dem Erfolg von ghostty plane ich, Zig für Spieleentwicklung auszuprobieren, sobald es 1.0 erreicht.
    Allerdings bin ich mir nicht sicher, ob die Art von Spielen, die ich mache, diese Leistung wirklich braucht.

  • Aussagen wie „Zig hat Sicherheit nicht aufgegeben und ist sicherer als unsafe Rust. Wenn man ohnehin unsafe Rust verwenden muss, kann Zig die bessere Wahl sein“ hört man ziemlich oft, aber ich verstehe sie jedes Mal nicht so recht.
    Besonders seltsam finde ich, dass der Autor zwar anerkennt, dass Sicherheit ein Spektrum ist, aber trotzdem empfiehlt, statt lokal begrenzter unsafe-Bereiche auf eine Sprache umzusteigen, in der weiterhin alles unsafe ist.
    Vielleicht lässt sich die abstrakte Maschine etwas leichter durchdenken, aber dieser Trade-off überzeugt mich nicht.