Was Zigs `comptime` nicht tut

• Zigs comptime-Funktion bietet eine sehr leistungsfähige Compile-Time-Evaluation, ist aber bewusst eingeschränkt
• Bei der Ausführung von Code zur Compile-Zeit ist kein Zugriff auf Host-Informationen möglich; das Design ist für Cross-Compilation geeignet
• Dynamische Codegenerierung, DSLs, RTTI, I/O usw. werden nicht unterstützt; stattdessen wird explizite typbasierte Codespezialisierung verwendet
• RTTI kann selbst implementiert werden; Typinformationen, die nur zur Compile-Zeit existieren, lassen sich für die Nutzung zur Laufzeit rekonstruieren
• Mit comptime lassen sich neue Typen erzeugen, aber keine APIs erweitern; benutzerdefinierte Methoden können nicht hinzugefügt werden

---

Was Zigs comptime nicht tut

• Obwohl Zigs comptime leistungsfähige Funktionen für Generics, bedingte Kompilierung, Serialisierung, ORMs usw. bietet, sind einige Fähigkeiten ausdrücklich eingeschränkt
• Gerade diese Einschränkungen machen Zigs Design einfacher und vorhersehbarer

• Kein Zugriff auf Host-Informationen (No Host Leakage)

  • comptime-Code arbeitet nicht bezogen auf das System, auf dem der Code ausgeführt wird, sondern auf die Zielplattform
  • In Zig können zur Compile-Zeit keine Informationen wie Endianness oder Pointer-Größe des Host-Systems verwendet werden
  • Das dient der Sicherstellung von Sicherheit im Hinblick auf Cross-Compilation
  • Im Beispielcode unterscheidet sich die Byte-Ausgabe einer Zahl im BF16-Format je nach Zielplattform

• Keine stringbasierte Codegenerierung (No #eval)

  • Zig bietet keine Funktionen zur dynamischen Codegenerierung wie Cs #include, Mixins in D oder Rust-Makros
  • Stattdessen wird partielle Auswertung (partial evaluation) auf Basis von comptime-Argumenten unterstützt
  • Wenn bestimmte Argumente zur Compile-Zeit bekannt sind, bleibt nur der entsprechende Zweig erhalten, wodurch Code optimiert werden kann

• Keine DSL-Syntaxerweiterungen (No DSLs)

  • In Zig gibt es keine Möglichkeit, benutzerdefinierte Syntax zu erstellen wie in Lisp oder Rust
  • Alle Daten werden nur in Form von Werten (values) nach der Zig-Syntax übergeben
  • Eingeschränkte DSLs wie Format-Strings (printf) können nur als comptime-Strings implementiert werden

• Keine Laufzeit-Typinformationen (No RTTI)

  • Zig kann sich ähnlich wie dynamische Sprachen wie Python verhalten, aber Typinformationen existieren ausschließlich zur Compile-Zeit
  • Damit es auch zur Laufzeit funktioniert, muss man eigene RTTI-Strukturen definieren und per Pointer manipulieren
  • Beispiel: Definition einer RTTI-Struktur mit Namen und Offsets von Struct-Feldern und Zugriff auf Felder per Pointer

• Keine neuen APIs erzeugen (No New API)

  • In Zig kann man mit comptime neue Typen erzeugen, aber diesen Typen keine Methoden hinzufügen
  • Eine API-Erweiterung wie bei Rusts Derive-Makros ist nicht möglich
  • Bei der Implementierung von JSON-Serialisierung kann keine Methode wie .to_json() hinzugefügt werden; stattdessen wird ein globaler Funktionsaufruf mit Typargumenten verwendet

• Kein Compile-Time-IO (No IO)

  • Zigs comptime verbietet den Zugriff auf externe Ressourcen wie Dateisystem, Netzwerk oder Datenbanken
  • Dadurch werden Reproduzierbarkeit, Sicherheit und Cache-Nutzbarkeit verbessert
  • Wenn I/O nötig ist, sollte über das Build-System build.zig vorab erzeugter Zig-Code per Import eingebunden werden

• Zusammenfassung: El Disco (Balance zwischen Abstraktion und Einfachheit)

  • Zig bietet leistungsfähige Metaprogrammierungsfunktionen, sichert aber durch ein stark eingeschränktes Design Vorhersehbarkeit
  • Dank dieser Einschränkungen bleibt Zigs comptime praxisnah und leicht verständlich
  • Auch ohne komplexe Abstraktionen ist es im praktischen Einsatz nützlich, und es funktioniert klar nur mit den deklarierten Fähigkeiten

[GN⁺]

Hacker-News-Kommentar

• Zigs comptime hat einzigartige Eigenschaften

  • ersetzt verschiedene Funktionen aus anderen Sprachen
  • ist durch referenzielle Transparenz leicht zu verstehen
  • bietet durch Introspection leistungsstarke Möglichkeiten
  • ermöglicht einfaches und zugleich mächtiges Schreiben von Code, allerdings auf andere Weise als Lisp
  • Sprachen mit neuem Design und neuartigen Ansätzen sind selten

• Nachteile von Zigs comptime und Lösungsansätze

  • Code wird über zig build generiert und danach per @import kompiliert
  • bietet mehr Freiheit und unbegrenzte Ausführungszeit, aber nicht die Freiheit, Zig-Typen im aktuellen Kompilierungslauf als Werte zu erzeugen
  • ähnelt früheren Erfahrungen damit, Perl und Tcl an C anzubinden
  • die selbstkritische Haltung der Zig-Community wirkt manchmal irritierend

• Die aus Borges’ Geschichte zitierte spanische Formulierung bezieht sich auf einen nordischen Gott

• Flexibilität von comptime

  • wenn man während der Arbeit Typinformationen braucht, kann man sie als zusätzlichen Funktionsparameter übergeben
  • wenn es in bestimmten Situationen nicht möglich ist, einen Typ bereitzustellen, muss das Designproblem gelöst werden

• Wofür Zigs comptime bekannt ist

  • bietet viele Funktionen wie Generics, bedingte Kompilierung, Subtyping, Serialisierung, ORM usw.
  • auch andere Sprachen verfügen über ähnliche Möglichkeiten zur Compile-Time-Auswertung

• Lehrreicher Blogbeitrag

  • erklärt den Unterschied zwischen comptime for und inline for
  • bei der inline-Version kann die Länge nur zur Compile Time bekannt sein

• Positive Einschätzungen zu Zig und seinen Tools

  • ein Sicherheitsmodus wie in Rust wäre wünschenswert
  • ist C/C++ weit voraus
  • der Zig-Compiler ist sehr beeindruckend

• Interessante Aspekte von Zigs comptime

  • die Fähigkeit, Typen zur Compile Time als Werte darzustellen
  • ermöglicht Annäherungen an dynamische Sprachen oder Runtime-Reflection ohne Runtime-Overhead

• Verwirrung über Compile-Time-Codeausführung

  • Zweifel daran, ob Compile-Time-Code tatsächlich auf der lokalen Host-Maschine ausgeführt wird
  • Neugier darauf, warum Zig die Host-Plattform verbirgt
  • positive Einschätzung von Zigs Cross-Compile-Fähigkeiten