Mitchell Hashimoto sagt der Zig Software Foundation eine Spende von 300.000 US-Dollar zu

 (mitchellh.com)
1 Punkte von GN⁺ 2024-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • Mitchell Hashimoto und seine Frau haben der Zig Software Foundation 300.000 US-Dollar zugesagt und unterstützen damit öffentlich die unabhängige Entwicklung von Zig sowie den Betrieb der Stiftung
  • Die Spende wird über zwei Jahre hinweg mit 150.000 US-Dollar pro Jahr ausgezahlt; die erste Rate wurde bereits überwiesen
  • Hashimoto verfolgt Zig seit 2019, begann 2021 damit zu arbeiten und leistet seit 2022 Beiträge in Form von Artikeln und Compiler-Beiträgen
  • Auch sein 2023 veröffentlichtes Terminal-Projekt Ghostty wurde in Zig geschrieben, und inzwischen fließt der Großteil seiner Coding-Zeit in Zig
  • Zig hat bis zu mehr Stabilität und breiterer industrieller Akzeptanz zwar noch einen Weg vor sich, doch Hashimoto sieht darin ein Projekt mit starker Community und nachhaltigem Finanzierungsmodell und empfiehlt Spenden

Zusage über 300.000 US-Dollar

  • Mitchell Hashimoto und seine Frau haben zugesagt, der Zig Software Foundation 300.000 US-Dollar zu spenden
  • Die Auszahlung erfolgt über zwei Jahre mit jeweils 150.000 US-Dollar pro Jahr
    • Die erste Rate wurde bereits überwiesen
  • Die ZSF erläutert in einer separaten Ankündigung die Mission der Stiftung und die konkreten Verwendungszwecke der Mittel

Warum Hashimoto Zig unterstützt

  • Hashimoto verfolgt das Zig-Projekt seit etwa 2019 und teilte 2021 öffentlich seine Erwartungen an das Projekt
  • Seit Ende 2021 nutzt er Zig und begann Anfang 2022, über Zig zu schreiben und zum Compiler beizutragen
  • Seitdem hat er die Zig-Repositories mit Dutzenden Code-Beiträgen weiter unterstützt
  • Sein 2023 vorgestelltes Terminal-Projekt Ghostty wurde in Zig geschrieben, und derzeit verbringt Hashimoto den Großteil seiner Coding-Zeit mit Zig

Einschätzung zu Zig und der ZSF

  • Hashimoto sieht in Zig ein unabhängiges Softwareprojekt, das Veränderung und Wirkung erzielen kann
  • Zig begann als Leidenschaftsprojekt und hat diesen Charakter bis heute bewahrt; er bewertet sowohl die Projektführung als auch die Community als stark
  • Das Finanzierungsmodell sei transparent und nachhaltig, technisch sei das Projekt ehrgeizig und innovativ, zugleich aber praktisch und realistisch
  • Bis zu mehr Stabilität und einer breiteren industriellen Akzeptanz werde es noch Zeit brauchen, doch er hält den Weg dorthin und die Chancen für klar erkennbar
  • Etwa ein Drittel der ZSF-Finanzierung stammt aus privaten Spenden; wer kann, dem empfiehlt er eine Spende

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-02
Hacker-News-Kommentare

  • Der Satz „Normalerweise machen wir unsere Wohltätigkeit privat, aber angesichts meines Hintergrunds mache ich bei Zig eine Ausnahme, weil ich denke, dass öffentliche Unterstützung dem Projekt tatsächlich helfen kann“ hat mich irgendwie berührt
    Schwer genau auszudrücken, aber die grundlegende Würde darin ist lobenswert

    • Ich hatte ein ähnliches Gefühl, aber vielleicht in die entgegengesetzte Richtung
      Heißt das, dass öffentliche Unterstützung bei den anderen wohltätigen Aktivitäten nicht hilft? Wenn ja, würde mich interessieren, was das für Aktivitäten sind. Natürlich kann man mit seinem Geld am Ende machen, was man will, aber die Formulierung klang etwas seltsam
    • Wenn es an sich schon einen Wert hat, beim Spenden den eigenen Namen daran zu knüpfen, ergibt das völlig Sinn
      In diesem Fall könnte diese öffentliche Unterstützung sogar einen zusätzlichen Beitrag auslösen, der größer ist als die eigene Spende
    • Einfach zu sagen, dass man etwas unterstützt, an das man glaubt, und zu erklären, warum es einem wichtig ist, wirkt völlig natürlich
    • Ich frage mich, ob es an der öffentlichen Unterstützung liegt oder daran, dass wohltätige Aktivitäten normalerweise privat bleiben

  • Falls hier jemand von der Zig Foundation mitliest, würde ich dringend empfehlen, ein Job-Board einzurichten
    An Orten mit einer Leserschaft für ein bestimmtes Fachgebiet ist das fast eine kostenlose Einnahmequelle

    • Ich mache das

  • Vielleicht ist das eine dumme Frage, aber ich bin Webentwickler und begegne System-/Low-Level-Programmierung normalerweise nur aus Neugier
    Man hört oft, man solle, wo immer möglich, alles auf speichersichere Sprachen umstellen, aber Zig scheint diese Garantie nicht zu haben. Wenn Zig eine neue Sprache ist, dann dürfte der Haupteinsatz doch in neuen Projekten liegen; sollte man dann nicht gleich mit einer speichersicheren Sprache anfangen? Wenn der Vorteil von Zig darin liegt, „moderner als C und einfacher als Rust“ zu sein, verstehe ich den Reiz, aber schwächt mangelnde Speichersicherheit diesen Vorteil nicht ab?

    • Speichersicherheit ist ein nützliches Konzept, aber weder ein Allheilmittel noch eine binäre Eigenschaft
      Wenn am Ende nur Sicherheit das Ziel wäre, hätte JavaScript auch gereicht. Sicheres Rust garantiert Speichersicherheit und ist deshalb ein großer Fortschritt für die Systemprogrammierung, aber nicht immer die endgültige Antwort. Je nach Anwendung gibt es Trade-offs, und ich persönlich halte es für wichtiger, ob sich Sicherheit leicht erreichen lässt, als für garantierte Sicherheit. Das Problem bei C und C++ war, dass es viel zu schwer war, sie sicher zu machen
    • In den Bereichen, in denen Zig wirklich glänzt, würde derselbe Code in Rust wahrscheinlich viel unsafe enthalten und damit faktisch die Speichersicherheitsfunktionen abschalten
      Ob Zig in der Praxis wirklich unsicherer als Rust ist, muss man wohl noch abwarten. In beiden Fällen braucht man viele Tests, um Programme sicher zu machen, und Rust beseitigt nicht auf magische Weise alle Bugs. Wenn man in Zig mit Debug-Modus ausreichend testet, dürfte man die meisten Speichersicherheitsfehler finden. Wenn ich allerdings so etwas wie einen Webbrowser bauen würde, würde ich wohl Rust nehmen
    • Auch mit C/C++ kann man sehr schnellen und sehr sicheren Code schreiben
      Man muss sich nur die Spielebranche ansehen oder allgemein die Industrie aus der Zeit, als Software noch auf Datenträger gebrannt und so verteilt werden musste. Das heutige Problem ist, dass die Sprachkomplexität zugenommen hat und das durchschnittliche Kompetenzniveau von Softwareentwicklern gesunken ist. Google hat Go zum Teil entwickelt, um dieses Problem anzugehen, und Rust ist eine weitere Sprache, bei der Speichersicherheit ein zentraler Teil des Entwurfs ist. Ein weiterer Grund, warum Rust das Schreiben sichererer Programme begünstigt, ist, dass es deutlich weniger komplex als C++ ist. Es wird zwar auch immer komplexer, aber glücklicherweise ist das Konzept der Speichersicherheit in der Rust-Community tief verankert, sodass dieser Vorteil und die Gewohnheiten der Entwickler wohl bleiben werden, selbst wenn die Sprache komplexer wird
      Zig ist ebenfalls eine gute Wahl, wenn man Sicherheit wichtig findet. Es vereinfacht vieles mit Syntax wie defer und bietet verschiedene Targets und Werkzeuge, um Speichersicherheitsprobleme während der Entwicklung zu finden. Der Compiler erzwingt das nicht; stattdessen wird es während der Entwicklung und in Nicht-ReleaseFast-Builds zur Laufzeit erkannt, aber es ist trotzdem eine Verbesserung gegenüber C/C++
    • Ich weiß nicht, ob man Zig pauschal als „nicht speichersicher“ abstempeln sollte
      Es hat ziemlich viele Speichersicherheitswerkzeuge und -prüfungen, die es in C nicht gibt. Sicherheit ist ein Spektrum. C ist weniger sicher als C++, C++ weniger sicher als Zig, Zig weniger sicher als Rust, Rust weniger sicher als Java und Java weniger sicher als Python. Undefiniertes Verhalten und Speicherbeschädigung sind bei allen weiterhin möglich; der Unterschied ist nur, wie leicht es dazu kommt
    • Ich denke schon, dass mangelnde Speichersicherheit die Vorteile von Zig teilweise abschwächt
      Allerdings ist Zig noch keine fertige Sprache, deshalb ist ein endgültiges Urteil jetzt schwierig. Zig hat auch gute Speichersicherheitsfunktionen; es ist weder auf dem Niveau von JavaScript oder Rust noch einfach wie C. Als ich zuletzt nachgesehen habe, war Use-after-free ein großes Problem, und wenn das nicht gelöst wird, sehe ich keine Zukunft für Zig
      JavaScript ist zwar wirklich eine speichersichere Sprache, aber Laufzeitumgebung und Abstraktionsebene passen nicht zur Systemprogrammierung. Für Systemprogrammierung braucht man meiner Meinung nach etwas, das grundsätzlich speichersicher ist, aber Auswege bietet, sowie eine niedrige Abstraktionsebene, die ungefähr eine Stufe über dem virtuellen PDP-11 liegt, auf den Compiler und CPU meist abzielen. Es sollte Programmierern erlauben, im Modell der CPU-Ausführung zu denken, ohne in Details zu versinken, und außerdem sehr gute Interoperabilität mit C haben
      Rust hat das Erste meiner Meinung nach gut gelöst. Die Schwäche liegt beim Zweiten. Low-Level-Funktionen gibt es zwar, aber sie liegen unter einem Berg an Sprachkomplexität begraben. Außerdem erlaubt Rust einige vollständig sicheren Speicherverwaltungs-Muster nicht, sodass man zu oft unsafe verwenden oder den Code eher nach dem Lösungsraum als nach dem Problemraum verbiegen muss
      Zig ist beim Ersten schwächer. Es hat gute Funktionen, aber auch große Lücken. Beim Zweiten ist es dagegen ziemlich stark. Wünschenswert wäre, dass Zig grundlegende Speichersicherheit bietet, dabei aber deutlich flexibler als Rust ist und seine Vorteile bei niedriger Abstraktion und C-Interoperabilität behält

  • Als ich kürzlich gelesen habe, dass man auf Self-Hosting umgestellt hat, hatte ich den Eindruck, dass das ein besonders effizientes Projekt ist, das Spendengelder nicht verschwendet

  • „Schatz, es gibt da eine Programmiersprache, die ich wirklich liebe, und ich würde gern darüber reden“
    „Hm? …“
    „Ich mag diese Sprache so, so sehr, dass ich ein bisschen dafür spenden möchte …“
    „……Jetzt geht das schon wieder los……“

    • Oder es könnte auch so laufen
      „Klingt gut! Lass uns mit unserer Cirrus SF50 Vision hinfliegen und es Andrew Kelley persönlich übergeben“

  • Das sind eindeutig gute Nachrichten, aber zur Einordnung entspricht dieser Betrag ungefähr 0,75 bis 1 Jahresgehalt eines erfahrenen Compiler-Entwicklers
    Nur eine Vermutung, aber Microsoft gibt allein für TypeScript wahrscheinlich jedes Jahr das 10- bis 20-Fache davon aus, und für C++/C# vermutlich noch deutlich mehr

    • Es gibt zwar Entwickler, die so viel verdienen, und bei Unternehmen wie Microsoft oder Mozilla ist das noch wahrscheinlicher, aber wenn man den weltweiten Markt und kleine Compiler-Projekte betrachtet, verdienen auch viele erfahrene Compiler-Entwickler weniger als 150.000 Dollar pro Jahr
      Natürlich bestehen Entwicklerkosten nicht nur aus dem Gehalt. Trotzdem hatte ich oft den Eindruck, dass vergleichbare Stellen für Compiler-Entwickler, die sich in großen Tech-Unternehmen mit ANSI-Standard-Compilern beschäftigen, gegenüber freierer Arbeit ziemlich unerquicklich sind und daher stark den Charakter einer Gefahrenzulage haben
    • Die Rolle eines vergleichsweise neuen Projekts mit hohem Potenzial wie diesem kann für Menschen, die bereits von Zig überzeugt sind, eine ziemlich attraktive Gelegenheit sein
      Mit ausreichender Finanzierung kann es als Katalysator wirken, damit man nicht noch einen Zweitjob machen oder nur nachts und am Wochenende daran arbeiten muss

  • Ehrlich gesagt freue ich mich sehr auf Zig
    Es ist schlank und schnörkellos und keine Sprache, die von Elfenbeinturm-Leuten gebaut wurde, denen die praktische Nutzbarkeit egal ist. Es wurde auch nicht wie Haskell von einem Team aus Doktoren entworfen, scheint sich aber klar von nützlichen Ideen aus Rust, Haskell und anderen Sprachen inspirieren zu lassen. Es wirkt ziemlich spannend, Code in Zig zu schreiben

    • Ich freue mich auf ähnliche Weise auch auf Zig
      Die Garantien für Memory Safety sind vielleicht nicht so umfassend wie bei Rust, aber ich würde Zig eines Tages gern im Linux Kernel sehen. Alte C-Kernel-Programmierer könnten sich womöglich leichter an Zig als an Rust gewöhnen
    • Ich weiß, dass man mich im Zig-Lager für diese Ansicht nicht mögen wird, aber wenn man in vim oder VS Code zig fmt abschalten kann, dann setze ich wieder Hoffnungen in Zig
      Wenn Stilpräferenzen erzwungen werden, hinterlässt das bei mir einen bitteren Nachgeschmack. Es wirkt wie eine Haltung, die Entwickler nicht respektiert, die eine Sprache als Werkzeug nutzen. Es könnte auch ein Signal für tieferliegende Probleme bei Community-Beteiligung und Offenheit gegenüber anderen Perspektiven sein, und bei Zig scheint es solche Probleme tatsächlich zu geben[0]
      Firmen, die einheitlichen Code brauchen, können einfach einen Linter laufen lassen, und bei Wochenendprojekten interessiert mich außer meinen eigenen Stilpräferenzen gar nichts. Es ist eine Frage, ob Zig eine Sprache für Erwachsene ist oder nicht. Wenn ich mich ohnehin zu einer bestimmten Art des Codens zwingen lassen muss, gibt es keinen Grund, nicht einfach Rust zu verwenden, das einem obendrein kostenlos Memory Safety mitliefert
      [0] https://github.com/ziglang/zig/issues/16270