ミッチェル・ハシモト氏、Zig Software Foundationに30万ドルの寄付を約束

 (mitchellh.com)
1 ポイント 投稿者 GN⁺ 2024-10-02 | 1件のコメント | WhatsAppで共有
  • Mitchell Hashimoto夫妻が Zig Software Foundation に30万ドルを約束し、Zigの独立した開発と財団運営を公に支援
  • 寄付金は2年間にわたり 年15万ドル ずつ支払われ、最初の分割金はすでに送金済み
  • Hashimoto氏は2019年からZigを見守り、2021年に利用を開始、2022年から執筆や コンパイラへの貢献 を続けている
  • 2023年に公開したターミナルプロジェクト Ghostty もZigで書かれており、現在は彼のコーディング時間の大半がZigに使われている
  • Zigはまだ安定性とより広い業界採用に向けて課題を残しているが、Hashimoto氏は強いコミュニティと持続可能な資金モデルを備えたプロジェクトと見て寄付を勧めている

30万ドルの寄付を約束

  • Mitchell Hashimoto氏と妻は Zig Software Foundation に 30万ドル を寄付することを約束
  • 支払いは2年間にわたり毎年 15万ドル ずつ行われる仕組み
    • 最初の分割金はすでに送金済み
  • ZSFは別の 告知 で、財団の使命と具体的な資金の使途を説明している

Hashimoto氏がZigを支援する理由

  • Hashimoto氏は2019年ごろから Zigプロジェクト を見守っており、2021年にはプロジェクトへの期待を公に共有した
  • 2021年後半からZigを使い始め、2022年初頭から Zig関連の記事 を書き、コンパイラに貢献 し始めた
  • その後もZigリポジトリに 数十件のコード貢献 を続けている
  • 2023年に公開したターミナルプロジェクト Ghostty は Zigで書かれて おり、現在Hashimoto氏はコーディング時間の大半をZigに使っている

ZigとZSFに対する評価

  • Hashimoto氏はZigを 変化と影響力 を生み出せる独立系ソフトウェアプロジェクトと見ている
  • Zigは情熱プロジェクトとして始まり、今もその性格を保っており、プロジェクト運営とコミュニティは強いと評価している
  • 資金モデルは透明で持続可能であり、技術的には野心的で革新的でありながら、実用的かつ現実的だと見ている
  • 安定性とより広い業界採用にはまだ時間が必要だが、そこに到達する道筋と機会は明確だと判断している
  • ZSFの資金の約 3分の1 は個人寄付によるもので、可能な人には 寄付 を勧めている

関連記事

1件のコメント

 
GN⁺ 2024-10-02
Hacker News のコメント

  • 「私たちの慈善活動は通常非公開だが、私の経歴を考えると、Zig への公開の支持がプロジェクトに実際に役立つ可能性があると思い、例外とする」という一文が妙に心に響いた
    うまく言い表すのは難しいが、そこにある基本的な品位は称賛に値する

    • 自分も似たように感じたが、もしかすると逆方向だった
      ほかの慈善活動では公開の支持が役に立たないという意味なのか？ そうだとしたら、それらの活動はどういう性格のものなのか気になった。もちろん自分のお金で行う慈善なのだから結局は好きにしてよいが、表現は少し妙に聞こえた
    • お金を寄付しながら自分の名前を添えること自体に価値があるなら、十分筋が通る
      この場合、その公開の支持が本人の寄付額より大きな追加の貢献を引き出す可能性もある
    • 自分が信じる対象を支援すると簡潔に表明し、なぜ気にかけているのかを説明するのは、まったく自然だと思う
    • 公開の支持だからそうなのか、それとも慈善活動が通常非公開だからそうなのかが気になる

  • Zig Foundation の関係者が見ているなら、求人掲示板を作ることを強く勧める
    特定分野の読者がいる場所では、ほとんどタダ同然の収益源に近い

    • 自分がやってみる

  • 愚かな質問かもしれないが、Web 開発者なのでシステム／低レベルプログラミングにはたいてい好奇心で触れる程度だ
    可能な場合はすべてメモリ安全な言語へ移行すべきだと言われているが、Zig にはそうした保証がないように見える。Zig が新しい言語なら、主な用途は新規プロジェクトのはずで、そうならメモリ安全な言語で始めるべきではないかと思う。Zig の利点が「C より現代的で Rust より単純」ということなら魅力は理解できるが、メモリ安全性が不足していると、その利点は弱まるのではないか？

    • メモリ安全性は有用な概念だが、万能薬でも二分法でもない
      最終目標が安全性だけなら JavaScript でも十分だったはずだ。安全な Rust はメモリ安全を保証するのでシステムプログラミングでは大きな改善だが、常に最終解というわけではない。アプリケーションによってトレードオフがあり、個人的には保証された安全性よりも、安全性を容易に達成できるかのほうが重要だと思う。C と C++ の問題は、安全に作るのがあまりに難しかったことにある
    • Zig が本当に輝く領域では、Rust で同じコードを書くと unsafe が多く入り、実質的にメモリ安全機能を切ることになる可能性が高い
      実際に Zig が Rust より安全性で劣るのかは、まだ見極める必要がある。どちらにせよプログラムを安全にするには多くのテストを書く必要があり、Rust がすべてのバグを魔法のように消してくれるわけではない。Zig でもデバッグモードで十分にテストすれば、ほとんどのメモリ安全バグを捕まえられるはずだ。それでも Web ブラウザのようなものを作るなら Rust を使うと思う
    • C/C++ でも非常に高速で非常に安全なコードは書ける
      ゲーム業界や、ソフトウェアをディスクに焼いて配布しなければならなかった時代の産業全般を見ればよい。今の問題は、言語の複雑さが増し、ソフトウェア開発者の平均的な熟練度が下がったことにある。Google が Go を作ったのも、ある程度この問題を解くためだったし、Rust はメモリ安全性を設計の中核に据えた別の言語だ。Rust がより安全なプログラム作成に有利なもう一つの理由は、C++ よりはるかに複雑でない点にある。次第に複雑にはなっているが、幸い Rust コミュニティにはメモリ安全性という概念が深く根付いているため、言語が複雑になっても、その利点と開発者たちの習慣は残り続けるだろう
      Zig も安全性を重視するなら良い選択肢だ。defer のような構文で単純化し、開発中にメモリ安全の問題を捕まえるための複数の実行ターゲットとツールを提供している。コンパイラが強制するのではなく、開発／非 ReleaseFast ビルドでランタイムに捕まえる方式だが、それでも C/C++ よりは改善された形だ
    • Zig 全体を「メモリ安全でない」と決めつけるのはよく分からない
      C にはないメモリ安全ツールと検査がかなり豊富にある。安全性はスペクトラムだ。C は C++ より安全でなく、C++ は Zig より安全でなく、Zig は Rust より安全でなく、Rust は Java より安全でなく、Java は Python より安全でない。未定義動作とメモリ破壊はどれでも依然として起こり得て、違いはどれだけ起こりやすいかだ
    • メモリ安全性の不足は Zig の利点を部分的に弱めていると思う
      ただし Zig はまだ完成した言語ではないので、現時点で断定するのは難しい。Zig にも良いメモリ安全機能はあり、JavaScript や Rust の水準ではないが C と同じでもない。以前確認したときは解放後使用が大きな問題で、これを解決できなければ Zig に未来はないと思う
      JavaScript は本当にメモリ安全な言語だが、ランタイムと抽象化レベルがシステムプログラミングには合わない。システムプログラミングには、基本的にメモリ安全でありながら逃げ道があり、コンパイラと CPU が概ね目標にしてきた仮想 PDP-11 より一段上くらいの低い抽象化が必要だと思う。プログラマが CPU の実行モデルに合わせて考えられる一方で、細部に埋もれないようにし、C との相互運用性も非常に高くなければならない
      Rust は一つ目はうまくやったと思う。弱点は二つ目だ。低レベルの機能はあるが、言語機能の複雑さの山の下に埋もれている。また、完全に安全なメモリ管理パターンの一部を許可しないため、unsafe を頻繁に使いすぎるか、問題領域ではなく解決領域に合わせてコードをねじ曲げなければならない
      Zig は一つ目が弱い。良い機能もあるが大きな穴もある。一方で二つ目はかなり強い。望ましい方向は、Zig が基本的なメモリ安全性を提供しつつ、それを Rust よりはるかに柔軟に提供し、低い抽象化と C 相互運用の面での利点を維持することだ

  • 最近セルフホスティングに移行したというニュースを見て、寄付金を無駄にしない特に効率的なプロジェクトだという印象を受けた

  • 「ねえ、僕が本当に好きなプログラミング言語があるんだけど、ちょっと話したいんだ」
    「え？……」
    「その言語が本当に本当に好きだから、少し寄付したいんだ……」
    「……また始まった……」

    • あるいは、こうなるかもしれない
      「いいね！ 私たちの Cirrus SF50 Vision に乗って、Andrew Kelley に直接渡しに行こう」

  • 間違いなく良いニュースだが、見方を整理すると、この金額はコンパイラを扱う熟練開発者の年俸0.75〜1人分程度である
    推測だが、Microsoft は TypeScript だけでも毎年その10〜20倍は使っており、C++/C# などにはさらに多くを使っていそうだ

    • それだけ稼ぐ開発者もいるし、Microsoft や Mozilla のようなところではその可能性がより高いが、世界市場や小さなコンパイラプロジェクトまで含めれば、年15万ドル未満の熟練コンパイラ開発者も多くいるはずだ
      もちろん開発者コストは給与だけで終わらない。ただ、大手テック企業で ANSI 標準コンパイラを扱うコンパイラ開発者に近い仕事は、より自由な仕事に比べて実際の業務がかなり不快で、危険手当的な要素がかなり混ざっていると感じた
    • このような比較的新しく、潜在力の高いプロジェクトでの役割は、すでにZig に確信を持っている人にとってはかなり魅力的な機会になり得る
      適切な資金があれば、副業をしたり夜や週末だけ働いたりしなくても済むようにする触媒になる

  • 正直、Zig には非常に期待している
    無駄がなくシャープで、実際の使いやすさを気にしない象牙の塔の人が作った言語ではない。Haskell のように博士たちのチームが設計したものでもない一方で、Rust や Haskell などの有用なアイデアからは明らかに着想を得ているように見える。Zig でコードを書くのはかなり面白そうだ

    • 私も Zig には同じように期待している
      メモリ安全性の保証は Rust ほど包括的ではないかもしれないが、いつか Linux Kernel で Zig を見られたらいいと思う。昔ながらのカーネル C プログラマたちは、Rust より Zig のほうが適応しやすいかもしれない
    • こういう見解を出すと Zig 陣営に嫌がられるのは分かっているが、vim や VS Code のようなところで zig fmt を無効にできるようになったら、また Zig に期待をかけたい
      スタイルの好みが強制されると後味が悪い。言語を道具として使う開発者を尊重していない態度のように感じる。コミュニティ参加や異なる視点への開放性に、より深い問題があるというサインかもしれず、Zig には実際にそうした問題があるように見える[0]
      コードの一貫性が必要な会社はリンターを走らせれば十分で、週末プロジェクトでは自分のスタイルの好み以外には何の関心もない。Zig が大人のための言語なのかどうかの問題だ。どうせ特定のやり方でコーディングを強制されるなら、無料でメモリ安全性まで付いてくる Rust を使わない理由はない
      [0] https://github.com/ziglang/zig/issues/16270