Mitchell Hashimoto s’engage à faire un don de 300 000 dollars à la Zig Software Foundation

 (mitchellh.com)
1 points par GN⁺ 2024-10-02 | 1 commentaires | Partager sur WhatsApp
  • Mitchell Hashimoto et son épouse se sont engagés à verser 300 000 dollars à la Zig Software Foundation, soutenant publiquement le développement indépendant de Zig et le fonctionnement de la fondation
  • Le don sera versé sur 2 ans, à raison de 150 000 dollars par an, et le premier versement a déjà été effectué
  • Hashimoto suit Zig depuis 2019, a commencé à l’utiliser en 2021, puis a poursuivi depuis 2022 la rédaction d’articles et ses contributions au compilateur
  • Son projet de terminal Ghostty, dévoilé en 2023, a lui aussi été écrit en Zig, et la majeure partie de son temps de programmation est désormais consacrée à Zig
  • Zig a encore du chemin à parcourir avant d’atteindre une pleine stabilité et une adoption plus large dans l’industrie, mais Hashimoto considère qu’il s’agit d’un projet doté d’une communauté forte et d’un modèle de financement durable, et recommande d’y faire un don

Engagement de don de 300 000 dollars

  • Mitchell Hashimoto et son épouse se sont engagés à faire un don de 300 000 dollars à la Zig Software Foundation
  • Le versement est structuré sur 2 ans, avec 150 000 dollars par an
    • Le premier versement a déjà été effectué
  • La ZSF aborde, dans une annonce séparée, la mission de la fondation et l’utilisation concrète des fonds

Pourquoi Hashimoto soutient Zig

  • Hashimoto suit le projet Zig depuis 2019 environ, et a publiquement partagé son enthousiasme pour le projet en 2021
  • Il a commencé à utiliser Zig à la fin de 2021, puis a commencé début 2022 à écrire des articles sur Zig et à contribuer au compilateur
  • Depuis, il a poursuivi avec des dizaines de contributions de code au dépôt Zig
  • Son projet de terminal Ghostty, dévoilé en 2023, a été écrit en Zig, et Hashimoto consacre aujourd’hui la majeure partie de son temps de programmation à Zig

Évaluation de Zig et de la ZSF

  • Hashimoto considère Zig comme un projet logiciel indépendant capable de produire du changement et de l’impact
  • Zig a commencé comme un projet de passion, et conserve encore aujourd’hui cette nature ; il estime que le fonctionnement du projet et sa communauté sont solides
  • Il juge le modèle de financement transparent et durable, et considère le projet comme techniquement ambitieux et innovant, tout en restant pratique et réaliste
  • Il faudra encore du temps avant d’atteindre la stabilité et une adoption plus large dans l’industrie, mais il estime que la trajectoire et les opportunités pour y parvenir sont claires
  • Environ un tiers du financement de la ZSF provient de dons individuels, et il recommande aux personnes qui le peuvent de faire un don

À lire aussi

1 commentaires

 
GN⁺ 2024-10-02
Avis de Hacker News

  • La phrase « Nos actions philanthropiques sont généralement privées, mais vu mon parcours, je pense qu’un soutien public à Zig peut réellement aider le projet, donc je fais une exception » m’a étrangement touché
    C’est difficile à formuler exactement, mais il y a là une décence fondamentale qui mérite d’être saluée

    • J’ai ressenti quelque chose de similaire, mais peut-être dans le sens inverse
      Cela veut-il dire que le soutien public n’aide pas les autres actions philanthropiques ? Si oui, je me suis demandé de quel type d’actions il s’agissait. Bien sûr, au bout du compte, quand on fait un don avec son propre argent, on fait ce qu’on veut, mais la formulation m’a paru un peu étrange
    • Si le fait d’associer son nom à un don a une valeur en soi, alors cela se tient tout à fait
      Dans ce cas, ce soutien public pourrait attirer des contributions supplémentaires supérieures au montant de son propre don
    • Dire simplement qu’on soutient quelque chose en quoi on croit, et expliquer pourquoi cela nous importe, me paraît tout à fait naturel
    • Je me demande si c’est parce qu’il s’agit d’un soutien public, ou parce que ses actions philanthropiques sont généralement privées

  • Si quelqu’un de la Zig Foundation regarde, je recommande vivement de créer un tableau d’offres d’emploi
    Pour un site avec un lectorat spécialisé, c’est presque une source de revenus gratuite

    • Je vais m’en occuper

  • C’est peut-être une question naïve, mais comme je suis développeur web, je ne touche généralement à la programmation système/bas niveau que par curiosité
    On entend dire qu’il faut migrer vers des langages à sûreté mémoire dès que possible, mais Zig ne semble pas offrir ce genre de garantie. Si Zig est un nouveau langage, son principal usage sera sans doute de nouveaux projets ; dans ce cas, ne devrait-on pas commencer avec un langage à sûreté mémoire ? Si l’avantage de Zig est d’être « plus moderne que C et plus simple que Rust », je comprends l’attrait, mais l’absence de sûreté mémoire n’affaiblit-elle pas cet avantage ?

    • La sûreté mémoire est un concept utile, mais ce n’est ni une panacée ni une question binaire
      Si l’objectif final n’était que la sûreté, JavaScript aurait suffi. Le Rust sûr garantit la sûreté mémoire, ce qui constitue une grande amélioration pour la programmation système, mais ce n’est pas toujours la réponse définitive. Il y a des compromis selon les applications, et personnellement je pense que la facilité à atteindre la sûreté compte davantage que la sûreté garantie. Le problème de C et C++, c’est qu’il était trop difficile de les rendre sûrs
    • Dans les domaines où Zig brille vraiment, écrire le même code en Rust nécessiterait beaucoup de unsafe, ce qui revient probablement, en pratique, à désactiver les fonctions de sûreté mémoire
      Reste à voir si Zig est réellement moins sûr que Rust. Dans tous les cas, pour rendre un programme sûr, il faut écrire beaucoup de tests, et Rust ne fait pas disparaître magiquement tous les bugs. Avec Zig aussi, en testant suffisamment en mode debug, on devrait pouvoir attraper la plupart des bugs de sûreté mémoire. Cela dit, si je devais créer quelque chose comme un navigateur web, j’utiliserais sans doute Rust
    • On peut écrire du code très rapide et très sûr en C/C++
      Il suffit de regarder l’industrie du jeu, ou plus largement l’industrie à l’époque où les logiciels devaient être gravés sur disque pour être distribués. Le problème actuel, c’est que la complexité des langages a augmenté et que le niveau moyen des développeurs logiciels a baissé. Google a créé Go en partie pour résoudre ce problème, et Rust est un autre langage qui place la sûreté mémoire au cœur de sa conception. Une autre raison pour laquelle Rust favorise l’écriture de programmes plus sûrs, c’est qu’il est beaucoup moins complexe que C++. Il devient certes de plus en plus complexe, mais heureusement, la notion de sûreté mémoire est profondément ancrée dans la communauté Rust, de sorte que même si le langage se complexifie, cet avantage et les habitudes des développeurs resteront
      Zig est aussi un bon choix s’il accorde de l’importance à la sûreté. Il simplifie les choses avec une syntaxe comme defer, et fournit plusieurs cibles d’exécution et outils pour détecter les problèmes de sûreté mémoire pendant le développement. Ce n’est pas imposé par le compilateur ; c’est détecté à l’exécution dans les builds de développement/non-ReleaseFast, mais cela reste une amélioration par rapport à C/C++
    • Je ne suis pas sûr qu’il faille qualifier tout Zig de « non sûr pour la mémoire »
      Il dispose d’un ensemble assez riche d’outils et de vérifications de sûreté mémoire que C n’a pas. La sûreté est un spectre. C est moins sûr que C++, C++ est moins sûr que Zig, Zig est moins sûr que Rust, Rust est moins sûr que Java, et Java est moins sûr que Python. Les comportements indéfinis et les corruptions mémoire restent possibles dans tous ces langages ; la différence tient à la facilité avec laquelle ils se produisent
    • Je pense que le manque de sûreté mémoire affaiblit en partie les avantages de Zig
      Cela dit, Zig n’est pas encore un langage terminé, donc il est difficile de trancher maintenant. Zig possède de bonnes fonctionnalités de sûreté mémoire, et même s’il n’est pas au niveau de JavaScript ou de Rust, il n’est pas non plus équivalent à C. La dernière fois que j’ai vérifié, l’utilisation après libération était un gros problème, et si Zig ne parvient pas à le résoudre, je ne vois pas d’avenir pour lui
      JavaScript est un vrai langage à sûreté mémoire, mais son runtime et son niveau d’abstraction ne conviennent pas à la programmation système. Pour la programmation système, il faut selon moi un langage sûr par défaut pour la mémoire, mais avec des échappatoires, et avec un niveau d’abstraction bas, à peine au-dessus du PDP-11 virtuel que les compilateurs et les CPU ont généralement pris pour cible. Il doit permettre au programmeur de penser selon le modèle d’exécution du CPU sans se noyer dans les détails, et offrir une très bonne interopérabilité avec C
      Rust a, à mon avis, bien réussi le premier point. Sa faiblesse est le second. Il possède des fonctionnalités de bas niveau, mais elles sont enfouies sous un amas de complexité des fonctionnalités du langage. Il interdit aussi certains schémas de gestion mémoire parfaitement sûrs, ce qui oblige à utiliser unsafe trop souvent, ou à tordre le code pour l’adapter à l’espace des solutions plutôt qu’au domaine du problème
      Zig est faible sur le premier point. Il a de bonnes fonctionnalités, mais aussi de grosses lacunes. En revanche, il est assez fort sur le second. Ce que j’aimerais, c’est que Zig fournisse une sûreté mémoire par défaut, mais de manière beaucoup plus flexible que Rust, tout en conservant ses avantages en matière de faible abstraction et d’interopérabilité avec C

  • En voyant la nouvelle récente de son passage à l’auto-hébergement, j’ai eu l’impression que c’était un projet particulièrement efficace, qui ne gaspillerait pas les dons

  • « Chérie, il y a un langage de programmation que j’aime vraiment, et j’aimerais t’en parler »
    « Hein ?… »
    « J’aime vraiment, vraiment ce langage, alors j’aimerais faire un don… »
    « ……Et c’est reparti…… »

    • Ou alors ça pourrait se passer comme ça
      « Bonne idée ! Prenons notre Cirrus SF50 Vision et allons le remettre en main propre à Andrew Kelley »

  • C’est clairement une bonne nouvelle, mais pour remettre les choses en perspective, ce montant correspond à environ 0,75 à 1 an de salaire d’un développeur expérimenté travaillant sur des compilateurs
    À vue de nez, Microsoft dépense chaque année 10 à 20 fois plus que ça rien que pour TypeScript, et probablement bien davantage pour C++/C#, etc.

    • Il y a bien sûr des développeurs qui gagnent autant, et c’est plus probable dans des endroits comme Microsoft ou Mozilla, mais si l’on considère le marché mondial et les petits projets de compilateur, il doit y avoir beaucoup de développeurs de compilateurs expérimentés qui gagnent moins de 150 000 dollars par an
      Bien entendu, le coût d’un développeur ne se limite pas au salaire. Cela dit, j’ai eu le sentiment que les postes comparables, dans les grandes entreprises tech, consistant à travailler sur des compilateurs conformes aux normes ANSI, comportent une bonne part de prime de risque, tant le travail réel peut être assez désagréable par rapport à des tâches plus libres
    • Pour un projet relativement récent et à fort potentiel comme celui-ci, ce rôle peut représenter une opportunité assez attrayante pour quelqu’un qui est déjà convaincu par Zig
      Avec un financement adéquat, cela peut servir de catalyseur en évitant d’avoir à cumuler deux emplois ou à ne travailler dessus que le soir et le week-end

  • Franchement, Zig me semble très prometteur
    Il est épuré et agile, et ce n’est pas un langage conçu par des gens dans leur tour d’ivoire sans se soucier de l’usage réel. Il n’a pas non plus été conçu par une équipe de docteurs comme Haskell, tout en semblant clairement s’inspirer d’idées utiles venues de Rust, Haskell, etc. Écrire du code en Zig a l’air assez intéressant

    • Moi aussi, j’ai des attentes similaires vis-à-vis de Zig
      Ses garanties de sûreté mémoire ne sont peut-être pas aussi complètes que celles de Rust, mais j’aimerais bien voir un jour du Zig dans le Linux Kernel. Les vieux programmeurs C du noyau s’adapteraient peut-être plus facilement à Zig qu’à Rust
    • Je sais que ce point de vue déplaira au camp Zig, mais je recommencerai à croire en Zig quand il sera possible de désactiver zig fmt dans des outils comme vim ou VS Code
      Quand des préférences de style deviennent obligatoires, ça laisse un goût amer. Cela donne l’impression de ne pas respecter les développeurs qui utilisent le langage comme un outil. C’est peut-être aussi le signe d’un problème plus profond d’ouverture à la participation de la communauté et à d’autres points de vue, et Zig semble effectivement avoir ce problème[0]
      Pour les entreprises qui ont besoin de cohérence dans le code, il suffit de faire tourner un linter ; pour mes projets du week-end, je ne me soucie de rien d’autre que de mes propres préférences de style. La question est de savoir si Zig est ou non un langage pour adultes. Si l’on doit de toute façon m’imposer une certaine façon de coder, je ne vois aucune raison de ne pas utiliser Rust, qui offre en plus gratuitement la sûreté mémoire
      [0] https://github.com/ziglang/zig/issues/16270