/note/tech

Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn’t 1.0 - Andrew Kelley Explains

要約:

■ 1. Zigの誕生背景

  • デジタルオーディオワークステーション(DAW)開発の試みが出発点となる:
    • JavaScript: 高レベルすぎてコンピュータの能力に十分アクセスできない
    • Go: C ライブラリとの連携が困難、ガベージコレクタによりリアルタイム処理(音声処理)に不適
    • Rust: borrow checker の規則を満たすことに苦労し、変更のたびにコンパイルエラーが連鎖する
    • C++: タイプミスや小さなミスがメモリ破壊バグを引き起こし、デバッグに数週間を費やす
    • C++ (C スタイル): C++ コンパイラを使用しつつ C リンカでリンクする方法を試みたが同様の問題が継続
  • 「自分ならもっとうまくできる」という確信から Zig の開発に着手
  • 設計哲学: ツールチェーンの制約を前提とせず、コンピュータが根本的に何をできるかを起点に考える

■ 2. Zigの用途と設計思想

  • コンピュータへの完全な制御が必要な場面で使用する言語として位置付ける
  • 最高のパフォーマンスとメモリ効率の実現を目的とする
  • ユーザー体験の妥協を一切しない開発哲学を体現する

■ 3. 主な採用事例

  • Ghosty: Mitchell Hashimoto によるターミナルエミュレータ。高品質コードとファズテストで品質を担保
  • Tiger Beetle: 金融トランザクションデータベース。起動時にリソースを事前確保し以後動的割り当てを行わないため、レイテンシが予測可能かつ一貫している
  • Bun: JavaScript エンジン。グルーコードを Zig で記述。Anthropic に売却済み。AI 分野での Zig 活用が増加
  • Uber: Go コードのクロスコンパイル時に C コードも含めてビルドする目的で Zigcc を ARM64 向けに使用

■ 4. 命名の由来

  • Python スクリプトでランダムワードを生成し "Zig" を選択。命名当時、"Zig programming language" の Google 検索結果がゼロだったことが選定理由
  • マスコットは "Ziguana"(ジグアナ)

■ 5. 1.0 未リリースの理由と "Worse is better" への見解

  • 1.0 の意味はプロジェクトによって異なる(Go は長期間言語を凍結、Rust は早期タグ後も additions で変更を継続)
  • Zig Software Foundation は 501c3 非営利組織であり、投資家や締切に縛られない
  • 急いで悪い判断を固定化することなく、真に妥協のない成果物として 1.0 をリリースする方針
  • "Worse is better"(劣化版でも早く出す)哲学に対しては "doing more with less" を Zig の立場として提示
    • 少ないコストで大きな成果を出す最適点を目指す
    • コンパイル時機能の少ない複雑さから高いユーティリティを得る比率や、1 つのフラグで異なる OS・アーキテクチャをターゲットにできるツールチェーンにこの哲学が反映されている

■ 6. Zig Software Foundation の運営

  • 年間収入: 2024年は約 67 万ドル(100 万ドル未満、今年は近づきつつある)
  • 収入源: 個人ドナーと複数企業からの多様な寄付で構成。特定企業への依存なし
  • スポンサーの開発への影響: バグトラッカー・プルリクエスト・開発チャンネルを通じた一般参加者と同等の権限のみ
  • 支出の 91% がコントラクターへの報酬。Foundation の従業員は Andrew Kelley 1 名、アクティブなコントラクターは約 5 名
  • Andrew Kelley の年俸: 154,000 ドル(非営利設立時のニューヨーク市シニアエンジニア中央値)
  • 1 億ドルの提供を受けた場合の方針:
    • 銀行に預けて 100 年間の資金確保
    • チーム規模は 5〜10 人程度に抑える。大規模管理は動機付けにならない
  • 財務透明性: 非営利法人としての義務に加え、自主的な透明性開示がマーケティングと信頼構築に寄与

■ 7. コミュニティとインフラの選択

  • Reddit・Twitter(現X)からの撤退: SNS からの投資対効果が低下。Zigday 等のオフラインイベントに注力
  • GitHub から Codeberg への移行: GitHub の CI が正常に動作しなくなったことが主因
  • Codeberg を選んだ理由:
    • GitHub に近い UX で移行コストが低い
    • ドイツの非営利組織であり、営利企業に比べて長期的な安定性を評価
  • 移行後もスポンサー関係は良好。ノーストリングスアタッチドの寄付文化により支持者の理解を得られた
  • Codeberg への移行がコミュニティの成長を妨げるという懸念については、人々が Zig を発見する経路はトーク・ミートアップ・YouTube であり、コードフォージはマーケティング手段ではないとの見解

■ 8. LLVM からの脱却

  • LLVM をコアプロダクトの依存関係にしていたことは「ゲームエンジンに Unity を使うこと」に類比される誤り
  • 自前の x86 バックエンドにより、100 万行規模のコードベースで変更後 50 ミリ秒以下のインクリメンタルコンパイルを実現(LLVM では不可能)
  • 10 年以上のコンパイラ開発経験を経て「トレーニングホイールを外せる」と判断

■ 9. LLM・AI ポリシー

  • Zig プロジェクトは Issues・PR への LLM 使用を厳禁
  • 禁止の理由:
    • AI 生成の貢献は品質が低く、レビュー時間を無駄にする(200 件以上の PR がレビュー待ち)
    • コードレビューの目的はメンターシップであり、AI 使用者は成長せずコアチームに加わる可能性もない
    • Zig はプログラミング教育プロジェクトでもあり、AI 依存はその目的に反する
    • "None whatsoever" ポリシーにより判断コストをゼロにできる
  • 検出方法: 大量のレビュー経験から人間らしくないパターンを識別。最近は LLM テキストをロンダリングする傾向があり、より厳格なコントリビューターフィルタの導入を検討中
  • Zig の AI パラドックス:
    • MIT ライセンスのため AI 学習への使用を禁じられない(事実上パブリックドメインに近い)
    • Zig が使われることはその価値の証明と捉えており、矛盾として気にしていない
  • LLM と Zig コードの相性: 個人差があり、うまく機能するとの報告もある
  • Vibe コーディングについて: 技術的には興味深いが、少数企業による中央管理・有料サブスクリプション構造に否定的

■ 10. プログラミングの未来観

  • 人間は趣味としてコードを書き続ける
  • 趣味で作られたソフトウェアはユーザーを尊重する傾向がある
  • 企業製ソフトウェアはエンゲージメント指標優先で、ユーザーとの関係が敵対的になりがち
  • 尊敬するオープンソースプロジェクト:
    • Linux: 経済全体に恩恵をもたらすフリーソフトウェアの基盤
    • Blender: 商業ソフトウェアと競合しながら勝利する非営利オープンソース
    • VLC: 非営利組織として運営され、質の高いコミュニティ運営が評価される
  • ブラウザ多様性への懸念:
    • Chromium の市場支配を問題視
    • Mozilla の現状(ユーザーとのアライメントのずれ)に不満を持ちながら Firefox を使用
    • 代替が存在しない状況に課題感を感じている

■ 11. 技術的特徴と他言語との比較

  • C との比較:
    • Zig は C が持つすべての能力を保持しながら欠点を改善
    • C では符号あり整数のオーバーフロー挙動が固定されているが、Zig では wrap-around か no-overflow かを明示的に選択可能
    • C から Zig への移行はスムーズ。セグメンテーション違反時にスタックトレースが出力される
    • C で可能なすべての操作が Zig でも可能で、かつより少ないフットガンで実現できる
  • Rust との比較:
    • 型システム: Zig は Rust のようなトレイト・borrow checker を持たず、より単純。Rust はより型安全だが Zig はコードの単純さを優先
    • メモリ管理: Rust は RAII スタイルに誘導するが、Zig はアリーナアロケータなどをより明示的に使用。アプリケーションに特化したメモリ管理が一般的
    • CPU が何をすべきかを考えたい場合は Zig、型理論に沿ったコードを書きたい場合は Rust

■ 12. Zig のキラーフィーチャーと設計の特徴

  • キラーフィーチャー: 自己完結したツールチェーン
    • システム依存なしに任意の OS とアーキテクチャをターゲットにできる
    • プロジェクトのビルド手順が zig build 一行で完結する
  • 未使用変数をコンパイルエラーとして扱う:
    • バグを早期発見し開発効率を高める
    • エディタ設定で自動注釈付与が可能。設定の好みが異なる開発者が同一コードを共有できる
  • I/O インターフェース: バッファをインターフェース内に持つことで、パフォーマンスと再利用性の最適点を実現。実装の複雑さは意図的なもの

■ 13. 学習と開発環境

  • 入門者向けリソース: Ziglings(演習形式で言語全体を学べる)
  • C からの移行: スキルがそのまま転用でき、生産性が向上する
  • 最初のプログラミング言語としての Zig: コンピュータの仕組みを学べる。得た知識は他言語にも転用可能
  • Andrew Kelley 自身のセットアップ: ターミナル + Vim(言語仕様変更に対して堅牢なため)
  • ZLS(Zig Language Server): サードパーティ実装の言語サーバー。Zig Software Foundation とは独立した組織が運営
  • JetBrains 製品: クローズドソースのため未使用
  • 望ましい IDE 機能: 型情報に基づく高度なリファクタリングツール(関数抽出、変数リネーム、クエリベースの大規模変更など)
  • AI ツールのリネーム問題: 結果をレビューする必要があるため、確実な変数リネームツールより遅い

■ 14. BDFL(慈悲深き終身独裁者)モデル

  • 一貫したビジョン維持のため BDFL スタイルを採用
  • 委員会モデルの問題: 異なるユースケースへの妥協が製品品質の低下を招く
  • リスク: Andrew Kelley 離脱後は組織の腐敗(資金の影響)を防ぐ民主的ガバナンスが未確立
  • 長期的には民主的ガバナンスへの移行が必要と認識しているが、設計が未完了

■ 15. Andrew Kelley 個人について

  • Zig は「コンピュータへの神殿」であり、毎日ワクワクして作業に取り組む
  • 最大の課題: 非営利法人の事務作業(会計・税務など)
  • バーンアウトへのアドバイス:
    • 運動・睡眠・食事などの基本を整える
    • 仕事に価値を感じられない場合は転職か起業を検討
    • やむを得ない場合は仕事への投資を抑え、17時退社など私生活を充実させる
  • プログラミング以外の趣味: マラソン(1 回完走)、日本語学習(Portland の Yuko 先生に師事)
  • 成功の定義:
    • 多様な収入源と満足するユーザーが存在する点ですでに一定の達成
    • Go・Rust レベルの広い採用を将来の目標として設定
    • 商業利用も歓迎。企業からの寄付が収入多様化に寄与
  • Zig の立ち上げ判断: 2015 年当時に戻っても同じ選択をする。フルタイムでの開発開始日が人生最良の日