Interview mit Zig-Gründer Andrew Kelley

• Zig ist auf eine Systemprogrammiersprache ausgerichtet, die die Performance und Kontrolle von C beibehält, dabei aber footguns und Schwächen beim Debugging reduziert und CPU sowie Speicher direkt im Blick behält
• Das zentrale Unterscheidungsmerkmal ist die Toolchain: Ziel ist, ohne Systemabhängigkeiten mit einem einzigen zig build von jedem OS aus für jedes beliebige Ziel-OS zu bauen
• Die Verzögerung von 1.0 ist eine bewusste Entscheidung, um Abwärtskompatibilität nicht vorschnell zu versprechen; dank der gemeinnützigen 501(c)(3)-Struktur kann man sich auf langfristige Verbesserungen konzentrieren
• Die Zig Software Foundation verzeichnete 2024 Einnahmen von 670.000 US-Dollar und verfügt über verschiedene Förderstrukturen; wegen der Priorität stabil laufender CI wechselte sie von GitHub zu Codeberg
• Für Issues und Pull Requests gilt die Richtlinie no LLM, no AI; AI-Beiträge werden als negativ bewertet, weil sie Review-Zeit und Mentoring beeinträchtigen

---

Ausgangspunkt von Zig und Sprachdesign

• Hintergrund der Entstehung

  • Andrew Kelley probierte nacheinander JavaScript, Go, Rust und C++ aus, um eine digitale Audio-Workstation zu bauen, kam aber zu dem Schluss, dass jede dieser Sprachen Grenzen hat, wenn es darum geht, die gewünschte User Experience umzusetzen
  • JavaScript erschien ihm im Browser zu hochabstrakt, um die Fähigkeiten des Computers voll auszunutzen
  • Bei Go war die Interoperabilität mit C-Bibliotheken aus seiner Sicht unzureichend; außerdem hielt er es für ungeeignet für Echtzeitaufgaben wie Audio, bei denen Verarbeitung innerhalb fester Zeitfenster abgeschlossen sein muss, weil der Garbage Collector Glitches oder Aussetzer verursachen kann
  • Rust war vor Version 1.0 aus seiner Sicht schwer regelkonform zu nutzen; schon kleine Änderungen führten zu Kaskaden von Compilerfehlern, und selbst nachdem er einen Monat lang das Font-Rendering abgestimmt hatte, hatte er das Gefühl, kaum weiterzukommen
  • C++ war anfangs produktiv, doch kleine Tippfehler oder Versehen führten zu Speicherfehlern, deren Debugging Wochen dauern konnte; auch bei „C-style C++“ mit C++-Compiler und C-Linker blieben die footgun-Probleme bestehen
  • Der Ausgangspunkt von Zig war die Haltung, bei der User Experience keine Kompromisse einzugehen und sich nicht an dem zu orientieren, was die Toolchain erlaubt, sondern an dem, was ein Computer grundsätzlich leisten kann

• Warum Zig C ersetzen kann

  • Zig gilt als besser als C, weil es die Stärken von C beibehält und zugleich dessen Mängel und Schwächen verbessert
  • Andere Versuche, C zu ersetzen, hätten jeweils etwas aufgegeben, das C ausmacht; Zig hingegen soll alles können, was C kann, dabei aber footguns reduzieren und die Debugbarkeit erhöhen
  • C kennt bei signed integers nur optimierende Integer-Semantik und bei unsigned integers nur Wraparound-Semantik; Zig erlaubt dagegen bei signed wie unsigned die Wahl zwischen Wraparound und der Garantie, dass kein Overflow auftritt, und wird deshalb als noch „C-artiger“ als C beschrieben
  • Um C zu ersetzen, müsse man wiederverwendbaren Code für Betriebssystem-Kernel, Embedded-Geräte, Videospiele, WebAssembly und mehr schreiben können; wenn Zig Funktionen und Stabilität auf C-Niveau bietet, werde man sich für die Variante mit besserer Performance und weniger Bugs entscheiden

• Unterschied zu Rust

  • Der Kernunterschied zwischen Rust und Zig liegt im Typsystem
  • In Rust müssen Regeln wie die Fähigkeit eines Funktionsparameters zum Clone, unterstützte Interfaces oder zulässige übergebene Typen in einer Metasprache beschrieben werden
  • Zig verzichtet darauf und übergibt entweder konkrete Typen oder generische Typen, die ähnlich wie C++-Templates funktionieren
  • Der Trade-off ist: Rust-Code bietet mehr Garantien durch das Typsystem, Zig-Code dafür mehr Einfachheit beim Lesen
  • Rust setzt den mit C++ vertrauten RAII-Stil fort, bei dem Objekte andere Objekte referenzieren und automatisch zerstört werden, wenn die Referenzzahl null erreicht
  • In Zig sind Allocatoren deutlich expliziter; Referenzzählung ist zwar möglich, der entsprechende Code muss jedoch ausdrücklich geschrieben werden
  • In Zig werden häufig auf die Anwendung zugeschnittene Speicherallokationsmethoden genutzt: Man kann Zuweisungen mit einem Arena Allocator bündeln und gesammelt verwerfen, einen General-Purpose-Allocator für objektorientierte Ansätze verwenden oder hybride Verfahren für spezielle Anforderungen bauen
  • Code zu schreiben, der sich daran orientiert, was die CPU tun soll, und sie genau das ausführen lässt, gilt in Zig als natürlicher als in Rust

• Killer-Feature und Toolchain

  • Das Killer-Feature von Zig ist die Toolchain
  • Es handelt sich um eine Softwaresuite ohne Systemabhängigkeiten, die auf jedem Betriebssystem läuft und Code für jedes Zielbetriebssystem bauen kann
  • Wie leicht sich ein Projekt hacken lässt, erkennt man daran, ob man laut README viele Systempakete installieren muss, ob die Schritte je nach Betriebssystem unterschiedlich sind, wie viele Befehle zur Umgebungseinrichtung nötig sind und ob Docker oder spezielle Hardware erforderlich sind
  • Der beste Maßstab ist: eine Zeile, eine Abhängigkeit, funktioniert immer für alle; im README eines Zig-Projekts sollte als Build-Schritt allein zig build genügen

• Sprachregeln und IO-Interfaces

  • Die Regel, ungenutzte Variablen als Compilerfehler zu behandeln, spart bei groß angelegten Refactorings Zeit, weil sie Bugs aufdeckt; die Kosten für einen Kommentar zum Verwerfen einer Variablen seien gering
  • Dank der Editor-Unterstützung des ZLS-Teams lassen sich bei aktivierter Option ungenutzte Variablen automatisch verwerfen; werden sie später wieder genutzt, kann das Verwerfen wieder entfernt werden
  • Die neuen IO reader / IO writer-Interfaces sind eine Abstraktion, um wiederverwendbaren Code wie Bildladebibliotheken oder Serialisierungscode für Datenformate einmal zu schreiben
  • Ziel ist, Pakete zu trennen und dieselbe Logik in verschiedenen Anwendungen zu nutzen, indem man für konsumierte Daten einen reader und für Ausgaben einen writer als Parameter entgegennimmt
  • Wenn Lesen und Schreiben unter einer Abstraktionsschicht stattfinden, kann der Compiler die Logik schlechter verstehen und optimieren, was Performance kosten kann
  • Ein Design, das Puffer innerhalb des Interfaces einschließt, wird als optimaler Punkt gesehen, an dem der Compiler guten Code erzeugen und zugleich Wiederverwendbarkeit erreicht werden kann

Anwendungsfälle, 1.0 und die Richtung nach LLVM

• Konkrete Anwendungsfälle

  • Zig wird als Sprache vorgestellt, die man nutzt, wenn man den Computer vollständig kontrollieren, Performance und Speichernutzung maximal ausreizen und eine überzeugende User Experience schaffen möchte
  • Ghostty ist ein von Mitchell Hashimoto entwickelter Terminal-Emulator und wird als gutes Projekt in Bezug auf Code-Qualität, Community-Management und Fuzz-Testing bewertet
  • TigerBeetle ist eine Datenbank für Finanztransaktionen; anders als der Ansatz, OLTP auf relationale Datenbanken wie PostgreSQL aufzusetzen, wurde hier eine spezialisierte Datenbank gebaut, die als „tausendmal schneller“ als solche Strategien beschrieben wird
  • TigerBeetle allokiert beim Start den gesamten Speicher, der später verwendet werden soll, im Voraus und verzichtet danach auf dynamische Allokation, um die Latenz vorhersagbar und konsistent zu halten
  • Bun ist eine JavaScript-Engine, die JavaScriptCore und mehrere C++-Bibliotheken verwendet; der Glue Code ist in Zig geschrieben
  • Man geht davon aus, dass Bun kürzlich an Anthropic verkauft wurde, wodurch mehr Menschen Zig für AI-Zwecke einsetzen wollten
  • Uber verwendet Zigcc als C-Compiler, um den C-Code, von dem Go-Code abhängt, gemeinsam zu cross-kompilieren, und nutzt es für Builds auf ARM64-Ziele

• Warum sich 1.0 verzögert

  • Zig gibt es auch nach 10 Jahren noch nicht als 1.0, aber 1.0 wird im Kern als Versprechen der Abwärtskompatibilität verstanden, dessen Bedeutung sich je nach Projekt unterscheidet
  • Zum Vergleich: Go habe die Sprache nach 1.0 lange Zeit kaum angefasst, während Rust relativ früh 1.0 erreicht habe, aber über Editions die Abwärtskompatibilität erhalten und die Sprache dennoch deutlich verändern konnte
  • Die Zig Software Foundation ist kein Startup, sondern eine 501(c)(3)-Non-Profit-Organisation, daher gibt es keinen Druck von Investoren, keinen Verkauf und keinen Exit-Plan, und damit Zeit für langfristige Verbesserungen
  • Wenn 1.0 erscheint, soll es ein „kompromissloses Werk der Zuneigung“ sein, das nicht in schlechten, vorschnell festgeschriebenen Entscheidungen gefangen ist
  • Zu „worse is better“ heißt es, die Formulierung selbst ergebe sprachlich keinen Sinn; Zig strebt stattdessen more with less an
  • Ziel ist eine Toolchain, die mit einer comptime-Funktionalität geringer Komplexität großen Nutzen bringt und mit einem einzigen Flag für völlig andere Betriebssysteme und Architekturen kompilieren kann
  • Es gilt als sicher, dass die Adoption stark zunehmen wird, sobald 1.0 erscheint, aber das Ziel ist, eine Sprache für die nächsten 50 Jahre zu bauen
  • Mit dem kommenden Release 0.16 sollen die Ergebnisse dieser Entscheidungen allmählich sichtbar werden

• Warum man sich von LLVM löst

  • Der Grund für die Abkehr von LLVM ist die Einschätzung, dass man eine zentrale Abhängigkeit für das Kernprodukt vermeiden sollte
  • Als Beispiel wird das kompetitive Arcade-Spiel für 10 Spieler Killer Queen genannt, bei dem die Entwickler die Physik-Engine von Unity verwendeten, sodass schon kleine Änderungen oder Bugfixes an der Physik das Spielgefühl im Wettkampf veränderten und Updates auf neue Unity-Versionen unmöglich machten
  • Das wird als Fehler betrachtet, weil man eine Abhängigkeit im Kernprodukt geschaffen habe; bei Zig gehe es im Verhältnis zu LLVM darum, diesen Fehler zu korrigieren
  • LLVM wird mit „Stützrädern am Fahrrad“ verglichen; nach mehr als 10 Jahren Zig-Entwicklung habe man sehr viel mehr über Compiler-Bau gelernt und sehe sich nun in der Lage, die Stützräder abzunehmen und mit LLVM zu konkurrieren
  • Im eigenen x86-Backend sei inkrementelles Kompilieren möglich, bei dem selbst in großen Codebasen mit einer Million Zeilen nach Änderungen in unter 50 ms ein neues Binary erzeugt werde

• Name und Lernpfad

  • Der Name Zig wurde gewählt, als man nach einem kurzen Wort suchte, das für die Suche nach „Zig programming language“ null Treffer ergab, und ein Python-Skript dabei zufällige Wörter ausgab
  • Das Leguan-Maskottchen wird „ziguana“ genannt
  • Einsteigern wird Ziglings nachdrücklich empfohlen
  • Ziglings besteht aus einer Reihe von Übungen, in denen fast funktionierender Code absichtlich Probleme enthält und man beim Reparieren kaputter Programme neue Sprachfunktionen lernt
  • Der Wechsel von C zu Zig verlaufe besonders reibungslos; alles, was in C möglich ist, sei auch in Zig möglich, nur mit weniger footguns
  • Wenn es in C zu einem segmentation fault kommt, erscheint meist außer „segmentation fault“ nichts weiter und man ist auf die Fähigkeit angewiesen, einen Debugger zu benutzen; in Zig erhält man dagegen einen vollständigen Stack Trace, der auf jede Codezeile verweist
  • Ob Zig als erste Programmiersprache geeignet ist, hänge von der Person ab, gelte aber als gute Sprache für Menschen, die lernen wollen, wie Computer funktionieren, weil man damit CPU und Speicher versteht

Stiftungsbetrieb, Governance und Plattformwahl

• Finanzen und Förderstruktur

  • Die Gesamteinnahmen der Zig Software Foundation beliefen sich 2024 auf 670.000 US-Dollar.
  • Die Einnahmen stammen vielfältig von individuellen Förderern und Spenden mehrerer Unternehmen, sodass keine einzelne Partei die Entwicklungsrichtung erzwingen kann.
  • Wenn ein bestimmter Förderer fordere: „Mach das“, könne man ablehnen, und selbst wenn dieser Förderer dann kein Geld mehr gebe, halte man das Projekt weiterhin für überlebensfähig.
  • Förderer können nur auf die gleiche Weise Einfluss nehmen wie alle anderen, etwa durch Beteiligung am Bug-Tracker, das Einreichen von Pull Requests oder Gespräche in Entwicklungskanälen; einen separaten geheimen Kanal mit hoher Priorität gibt es nicht.
  • Andrew Kelleys Jahresgehalt beträgt 154.000 US-Dollar; es sei in der ersten Vorstandssitzung anhand des mittleren Gehalts eines Senior Software Engineers in der Stadt festgelegt worden, in der die gemeinnützige Organisation gegründet wurde.
  • Die Stiftung hat einen Angestellten und etwa fünf vergütete Vollzeitauftragnehmer; 91 % der Einnahmen des Vorjahres gingen an Auftragnehmer, die am Projekt arbeiten.
  • Auf ein bedingungsloses Angebot über 100 Millionen US-Dollar antwortete er, man würde es zwar annehmen, aber nicht für Wachstum ausgeben, sondern auf die Bank legen, damit man 100 Jahre lang keine Spenden sammeln müsse.
  • Derzeit leite er ein Team von fünf Personen; bei mehr als zehn könnte es belastend werden, und Manager einer Organisation mit 100 Personen wolle er nicht werden.

• 501(c)(3) und Transparenz

  • Es wird klargestellt, dass 501(c)(3) sich von 501(c)(6) unterscheidet.
  • 501(c)(6) ist eine Business League; die Rust Foundation wird als Form erwähnt, bei der Unternehmen wie Amazon, Netflix, Microsoft und Meta spenden, weil sie ein gemeinsames Interesse am Erfolg von Rust haben.
  • Eine 501(c)(3) darf kein Government Lobbying betreiben und existiert nicht für die Interessen von Unternehmen, sondern allein für ihr Mission Statement.
  • Ein Blogbeitrag, der Einnahmen und Ausgaben detailliert offenlegt, ist keine Pflicht, sondern freiwillige Transparenz; man sieht darin auch einen Vorteil für Vertrauen und Fundraising, weil die Kennzahlen gut sind.

• Warum GitHub und Social Media verlassen wurden

  • Reddit und Twitter wurden verlassen, weil das Posten auf diesen Seiten zunehmend so wenig relevant geworden sei wie Posts auf Slashdot oder Digg und weil er als Software Engineer die für Marketing aufgewendete Zeit minimieren wollte.
  • Statt Social Media, wo Algorithmen steuern, was sichtbar ist, oder wo man mit Trollen interagiert, sei es für das Wachstum der Community die bessere Investition, sich stärker auf Präsenzveranstaltungen und Meetups zu konzentrieren.
  • Der Hauptgrund für den Umzug des Haupt-Repositorys von Zig Ende 2025 von GitHub zu Codeberg war, dass GitHub die Continuous-Integration-Ergebnisse nicht mehr ordentlich bereitstellte und „einfach nicht funktionierte“.
  • Nach dem Umzug zu Codeberg funktionierten die Continuous-Integration-Server wieder.
  • GitHub Sponsors zu verlassen, war eine schwierige Entscheidung, weil dadurch Einnahmequellen verloren gehen konnten, doch damit man Software schreiben kann, müsse CI an erster Stelle funktionieren.
  • Nach dem Abschied von GitHub sei man finanziell „vollkommen in Ordnung“.
  • Zig ist Software unter der MIT-Lizenz, also eine bedingungslose Spende an die Welt der Software, und auch Förderung wird als bedingungslose Spende betrachtet.
  • Codeberg wurde gewählt, weil es GitHub im Wesentlichen ähnelt und der Wechsel daher einfach war, und weil es eine deutsche Non-Profit-Organisation ist.
  • Eine Code Forge ist kein Marketinginstrument für das Projekt; Menschen entdecken die Sprache nicht über GitHub oder Codeberg, sondern über Ankündigungen, Meetups, YouTube-Videos oder Gruppen wie das Zigday-Meetup.

• BDFL und langfristige Governance

  • Softwareprojekte müssen oft zwischen hierarchischer Kontrolle und demokratischen Verfahren wählen, und viele Projekte entscheiden sich wegen der Einfachheit für das BDFL-Modell.
  • Wenn eine Person die Kontrolle hat, trägt sie die Verantwortung, alles zu verstehen und eine konsistente Vision für das Projekt zu haben.
  • In Komitees können unterschiedliche, jeweils legitime Use Cases und Visionen aufeinanderprallen; wenn es kein einzelnes Design gibt, das beide Use Cases gleichzeitig erfüllt, kann ein Kompromiss zu einem schlechteren Produkt führen.
  • Auch wenn Andrew Kelley gehen sollte, könnten seine Kollegen das Projekt aus Sicht des Software Engineerings weiterführen, weil sie sehr kompetent seien.
  • Aus organisatorischer und stiftungspolitischer Sicht bleibe jedoch noch Arbeit; aus der Perspektive, dass Systeme, in denen Geld fließt, korrupt werden, sei derzeit eine starke hierarchische Führung nötig, die dem Einfluss von Geld widersteht.
  • Die Art, wie ein starker einzelner Anführer alles kontrolliert, ist nicht nachhaltig; für langfristige Nachhaltigkeit braucht es Demokratie, doch die Herausforderung besteht darin, sie so zu gestalten, dass sie mit der Zeit nicht durch den Einfluss von Geld korrumpiert wird.

• Erfolgskriterien

  • Aus einer Perspektive ist Zigs Erfolg bereits erreicht.
  • Es gibt vielfältige Einnahmequellen, sodass man von einer einzelnen Partei finanziell unabhängig ist; es gibt Nutzer, die zufrieden sind und Zig weiterverwenden, und etwa zweimal pro Jahr erscheinen Releases mit kontinuierlichen Verbesserungen.
  • Aus einer anderen Perspektive wünscht man sich eine breitere Adoption, und ein Maßstab für Erfolg ist ein Adoptionsniveau wie bei Go und Rust.
  • Kommerzielle Adoption ist nützlich, weil dadurch Unternehmensspenden möglich werden, doch auch bei Unternehmensspenden müsse man darauf achten, die Vielfalt zu bewahren.
  • Wenn man etwas allgemein Nützliches baut, wird es auch für Unternehmen nützlich, und das zeige sich auch daran, dass Menschen Zig für KI einsetzen.

AI-Richtlinien, Entwickler-Tools und die Zukunft des Programmierens

• Richtlinie „no LLM, no AI contribution“

  • Für Issues und Pull Requests verfolgt Zig eine strikte Richtlinie „no LLM, no AI“.
  • KI-Beiträge seien „nach wie vor Müll“ und hätten nicht nur keinen Wert, sondern sogar einen negativen, weil sie Review-Zeit wegnehmen.
  • Derzeit gibt es über 200 offene Pull Requests, und bei einem kleinen Entwicklerteam mit vielen Beitragenden ist die Review-Zeit der Engpass.
  • Bei KI-erstellten Beiträgen zeige sich laut ihm oft ein Muster: Nach einigen Review-Runden verstehen die Beitragenden den Inhalt nicht, kopieren das Feedback in einen Chat und waschen die zurückerhaltene Antwort dann als ihre eigene Formulierung rein.
  • Der zentrale Grund für Code-Reviews und das Annehmen von Beiträgen ist Mentoring; das Ziel ist, dass Beitragende später Kernteam-Mitglieder oder wertvollere Mitwirkende werden.
  • „Contributor poker“ ist der Prozess, mit begrenzter Zeit zu entscheiden, in wen investiert werden soll, um bessere Programmierer und Beitragende zu entwickeln.
  • Wer KI nutzt, falle aus seiner Sicht immer in die Kategorie einmaliger Beitragender mit geringem Investitionswert, lerne nicht dazu und habe keine Aussicht, Teil des Kernteams zu werden.
  • Das Zig-Projekt ist auch ein Bildungsprojekt, und Anleitung sowie Ausbildung für Lernende zu bieten ist Teil seiner Mission.
  • Würde man nur „gute AI PRs“ erlauben, bräuchte es jemanden, der das beurteilt; ein generelles Verbot ist dagegen leicht durchzusetzen.
  • Er räumt ein, dass es nicht immer einfach ist, KI-Erzeugnisse zu erkennen und dass einige womöglich hineingerutscht sind, aber beim Review vieler Pull Requests werde in manchen Fällen klar, dass das Verhalten nach Feedback nicht dem eines Menschen entspricht.

• MIT-Lizenz und KI-Training

  • Die Zig-Codebasis steht unter der MIT-Lizenz und ist für Menschen, die mit Softwarelizenzen nicht vertraut sind, praktisch nahe an Public Domain.
  • Sie kann für fast jeden Zweck verwendet werden; beim Kopieren von Code muss die Lizenz beigefügt werden, es gibt keine Gewährleistung, und Zig kann für Probleme nicht haftbar gemacht werden.
  • Es ist ironisch, dass große Unternehmen Zig-Code für KI-Training verwenden dürfen, Beiträge von KI zu Zig aber verboten sind.
  • Er sieht Zig klar als bedingungsloses Geschenk an die Welt und hält es deshalb für in Ordnung, wenn es für KI-Training verwendet wird.
  • Ob LLMs mit Zig-Code mehr Schwierigkeiten haben als mit Python oder JavaScript, habe er selbst nicht viel ausprobiert, aber Mitchell Hashimoto nutze KI-Coding in Ghostty umfangreich.
  • Eine Person mit dem Handle Rocker habe ein Tool entwickelt, das KI in Zig besser funktionieren lässt, und damit Erfolg gehabt.

• Vibe Coding und die Zukunft des Programmierens

  • Über längere Zeit an Projekten zu arbeiten, dabei Fähigkeiten zu erwerben und Berichte über gelöste Probleme zu lesen, rege die Fantasie an, lasse einen darüber nachdenken, was man selbst bauen könnte, und vermittele etwas mit emotionaler Bindung.
  • Vibe-Coding-Blogs nach dem Muster „Ich habe diese Version von Claude oder jene Version von OpenAI ausprobiert, und es hat erstaunlich gut funktioniert“ seien aus seiner Sicht nicht inspirierend.
  • Er betont, dass der Qualitätsmaßstab für Software nicht „erstaunlich, dass es keine Bugs gibt“ sein dürfe, sondern kompromisslose Perfektion.
  • In einem privaten Gespräch mit Richard Feldman habe er Vibe Coding ausprobiert und halte die Technologie selbst für grundsätzlich interessant.
  • Gleichzeitig empfinde er starken Widerstand dagegen, dass etwa vier Unternehmen alles zentral kontrollieren und vollständige Kontrolle über Modelle und Verhalten haben.
  • Er wolle nicht von einer Art des Programmierens wechseln, bei der man den eigenen Computer und den eigenen Strom nutzt, hin zu Closed-Source-Programmierung auf den Computern anderer Leute über das Netzwerk gegen ein Monatsabo.
  • Manche Menschen zahlten 300 US-Dollar im Monat, und ein solches Angebot erscheine ihm schlicht verrückt.
  • Auch in 10 oder 20 Jahren würden Menschen weiterhin Code schreiben; Programmieren mache Spaß und werde zumindest als Hobby immer bestehen bleiben.
  • Die besten Apps auf Telefonen und Computern seien von Menschen in ihrer Freizeit als Hobby gebaut worden, und der Wunsch nach freier Open-Source-Software und danach, Herr über die eigenen Geräte zu sein, werde nicht verschwinden.

• Editierumgebung und Refactoring-Tools

  • Es braucht eine robuste Arbeitsumgebung, in der sich Code weiter bearbeiten lässt, auch wenn sich die Zig-Syntax ändert.
  • Fortgeschrittene Tools wie tree-sitter oder Language Server setzen stabile Syntaxbäume oder eine stabile Sprache voraus; wenn die Sprache bricht, können sie mitbrechen.
  • Persönlich nutze er beim Schreiben von Zig lieber das Terminal und Vim als eine hochentwickelte Umgebung; Vim halte Veränderungen sehr gut stand.
  • ZLS steht für Zig language server, ist eine Implementierung des Language Server Protocol für Zig und ein Drittanbieterprojekt, das nicht von der Zig Software Foundation betrieben wird.
  • Die Zig-Website empfiehlt JetBrains-Produkte, aber Andrew Kelley hat sie nie verwendet, weil sie Closed Source sind.
  • Hochwertige Refactoring-Tools wie früher in JetBrains oder Eclipse, etwa zum Extrahieren von Funktionen, zum Umordnen von Funktionsparametern oder zum globalen Umbenennen von Bezeichnern, sieht er positiv.
  • Langfristig wünsche er sich Refactoring-Tools ähnlich einer Abfragesprache, die auf Basis von Typinformationen und anderen Hinweisen große Änderungen durchführen können.
  • Bei Aufgaben mit klar abgegrenztem Scope wie dem Umbenennen von Variablen könne ein verlässliches Tool sie so sicher erledigen, dass man den Commit erstellen könnte, ohne das Ergebnis noch prüfen zu müssen, weil man ihm zu 100 % vertraut.
  • Würde man dieselbe Aufgabe einem KI-Tool geben, müsste man den Code weiterhin prüfen; damit dauert es länger und ist eine schlechtere Wahl als ein verlässliches Refactoring-Tool.

Persönliche Motivation und Sicht auf Open Source

• Motivation und Herausforderungen, mit Zig weiterzumachen

  • Die Arbeit an Zig entspringt der Motivation, Computer zu lieben und dafür zu sorgen, dass Computer den Menschen dienen
  • Zig wird als optimistisches Geschenk beschrieben, das aus der Überzeugung entsteht, dass eine großartige Programmiersprache und Toolchain zu diesem Ergebnis führen werden
  • Nutzer zufriedenzustellen und eine starke User Experience zu schaffen, gibt große Erfüllung; das Gefühl, gute Software zu bauen, wird mit dem Gefühl eines Musikers verglichen, der auf der Bühne auftritt
  • Als schwierigster Teil wird die für den Betrieb einer Non-Profit-Organisation nötige Steuer- und Papierarbeit genannt
  • Sie ist zwingend notwendig, um rechtlich einwandfrei zu arbeiten und große Spenden annehmen zu können, derzeit übernimmt diese Arbeit jedoch Andrew Kelley
  • An manchen Tagen macht er Buchhaltung, an anderen programmiert er, und die Tage mit Programmierung gelten als die guten Tage
  • Die Änderung der IO-reader-/IO-writer-Schnittstellen in Zig 0.15 war das Ergebnis davon, einen optimalen Punkt zu finden, APIs zu entwerfen und zu testen sowie im Vergleich mit anderen Programmiersprachen neue Lösungen zu suchen; danach mussten jedoch sechs Monate lang die Standardbibliothek und Projekte im Ökosystem angepasst werden

• Burnout und Ratschläge

  • Burnout entsteht seiner Ansicht nach dann, wenn man viel Anstrengung investiert, aber dafür nur wenig Belohnung sieht
  • Andrew Kelley ist davor meist geschützt, weil er zwar viel Aufwand hineinsteckt, aber auch Belohnungen wie zufriedene Nutzer, Zig-Releases, Release Notes und Verbesserungen sieht
  • Arbeiten wie die IO-Änderungen, bei denen die Belohnung sich um mehrere Monate verzögert, können sich wie Burnout anfühlen, aber wenn die Belohnung am Ende kommt, wird es besser
  • Menschen mit Burnout rät er zuerst zu Bewegung, ausreichend Schlaf und gesunder Ernährung
  • Wenn man seine Arbeit hasst oder das Gefühl hat, dass das Unternehmen nichts Wertvolles für die Welt tut, und man trotzdem hart arbeiten muss, sind das Bedingungen für Burnout
  • In diesem Fall ist ein anderer Job oder der schwierige Weg, sich mit einer Gründung etwas Eigenes aufzubauen, eine Option; wer in einem „seelenlosen Konzern“ arbeitet, dem rät er, um 17 Uhr nach Hause zu gehen, etwas anderes zu machen und sich nicht zu sehr zu verausgaben

• Bewunderte Projekte und Browser-Vielfalt

  • Als erstes bewundertes Projekt wird Linux genannt
  • Eine Welt nur mit proprietären Betriebssystemen wäre deutlich schlechter; Linux habe nicht nur freien und Open-Source-Entwicklern genutzt, sondern auch Staaten und Unternehmen weltweit ermöglicht, kostenlos Geschäfte aufzubauen, was auch der Wirtschaft gutgetan habe
  • An zweiter Stelle steht Blender, das als Open-Source-Projekt und Non-Profit-Organisation hoch bewertet wird, weil es professionell eingesetzt wird und trotz Konkurrenz durch Unternehmen mit viel Geld und Entwicklerressourcen gewinnt
  • An dritter Stelle folgt VLC; er erinnert sich, dass, als er früher zu FFmpeg beitrug, die VLC-Organisation die Reisekosten zu den VideoLAN Dev Days für jemanden übernahm, der zu VLC oder einer abhängigen Bibliothek beigetragen hatte
  • Der Grund, Firefox zu verwenden, ist die Sorge um Browser-Vielfalt
  • Nachdem Microsoft den Internet Explorer eingestellt hat, bleiben als große Browser nur noch Chromium, Safari und Firefox; dass Chromium den Großteil des Marktes einnimmt, sieht er als Problem für das Web
  • Mit Mozilla ist er in letzter Zeit unzufrieden; obwohl es sich um eine Non-Profit-Organisation handelt, empfindet er dort viel Korruption und Beispiele dafür, dass die Interessen nicht mit denen der Nutzer übereinstimmen
  • Chromium steht für Google, Safari für Apple, Firefox wirkt auf dem absteigenden Ast, und es gibt zu wenige Alternativen; bis neue Browserprojekte ausgereift sind, wisse er nicht, was zu tun sei

• Würde er auch bei einer Rückkehr ins Jahr 2015 Zig starten?

  • Er antwortet, dass er auf jeden Fall Zig starten würde, selbst wenn er ins Jahr 2015 zurückkehren könnte
  • Der Tag, an dem er OkCupid verließ und Vollzeit mit Zig begann, war gemessen am weiteren Verlauf seines Lebens der beste Tag seines Lebens
  • Zig hat ihm tiefe Erfüllung, Unabhängigkeit, ein Gefühl des eigenen Werts und das Gefühl gegeben, einen Beitrag zur Gesellschaft zu leisten
  • Er empfindet sich grundsätzlich als jemanden, der schwer anzustellen ist; um glücklich zu werden, musste er sein eigener Chef sein, und erst nachdem er diesen Zustand erreicht hatte, fand er Glück

[GN⁺]

Lobste.rs-Meinungen

• Ich wünschte, auch Menschen außerhalb der Zig Software Foundation würden die Leidenschaft und Philosophie erkennen, mit der Andrew und das Kernteam das Projekt vorantreiben
  Man kann JetBrains kaum dafür kritisieren, das Interview etwas zugespitzter aufgemacht zu haben, um Viralität zu erzeugen, aber letztlich waren die besten Fragen nicht Zig gegen Rust, sondern die zu Zig als etwas, das aus Gemeinnützigkeit, Nachhaltigkeit und Zuneigung entsteht
  Ich finde, Andrew hat die menschliche Seite, die hinter dem Projekt still glüht, der Welt sehr gut gezeigt
  • Ehrlich gesagt hatte ich auch nicht den Eindruck, dass JetBrains das besonders in eine provokante Richtung gelenkt hat
    Das Video schien sich viel stärker an Menschen zu richten, die neugierig auf Zig sind, und an Leute, die sich für Projektorganisation interessieren, als an Personen, die Zig bereits intensiv genutzt haben, und hat einfach Themen aufgegriffen, die diesem Publikum wahrscheinlich bekannt sind
    Der Interviewer hat Andrews Aussagen auch für sich sprechen lassen, statt zusätzlich Öl ins Feuer zu gießen, und für ein Interview dieser Art war das sehr bedacht
    Ich musste allerdings über die Wörter lachen, die man als Untertitel einblenden wollte, denn ich weiß nicht, wie viele Leute sich für Zig interessieren, aber nicht wissen, was Linux ist oder was Abstraktion bedeutet
    Insgesamt war mein Eindruck sowohl von der Art, wie Zig präsentiert wurde, als auch vom Marketingteam von JetBrains sehr positiv
• Andrew erwähnte etwa in der Mitte das Tool, das ich gebaut habe, um Zig und die Nutzung mit AI zu unterstützen; für alle, die es ausprobieren möchten: Das Tool ist zigdoc: github.com/rockorager/zigdoc
  Im Grunde ist es ein Tool, mit dem man die Dokumentation der Zig-Standardbibliothek und der im Build-Graph gefundenen Abhängigkeiten über die Kommandozeile ansehen kann
• Ich mochte die Stelle in den letzten Sekunden des Videos sehr, in der Andrew sagt, dass er glücklich ist
• Die Formulierung „kompromisslose Arbeit aus Liebe“ trifft es
  Das Framing, 1.0 nicht zu überstürzen, ist reizvoll, aber Zig hat auch das Glück, Nutzer zu haben, die die Unruhe von Veränderungen im Ökosystem mittragen
• Im Embedded-Bereich war C über Jahre hinweg das Hauptwerkzeug
  Nicht C++, sondern einfach C
  Ich habe die ganze Zeit überlegt, ob mein nächstes Embedded-Projekt mit Zig oder mit Rust umgesetzt werden soll, aber jetzt fühlt es sich an, als sei „die Zeit gekommen“
  Dieses Interview könnte für mich der ausschlaggebende Moment sein, und es hat einen Gesamtton, mit dem ich mich stark identifizieren kann
• Die Antwort darauf, warum Zig sich von LLVM lösen will, war wirklich hervorragend
  Sie hat sehr gut den Bereich behandelt, in dem das Team mehr Kontrolle haben sollte, weil er zu den Kernfunktionen von Zig gehört