Zigの創始者 Andrew Kelley へのインタビュー

 (youtube.com)
2 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Zig は、C の性能と制御力を維持しながら、footgun とデバッグ面の弱さを減らし、CPU とメモリを直接意識するシステム言語を志向している
  • 中核となる差別化要素は ツールチェーン であり、システム依存なしに、どの OS 上で実行しても、どの OS 向けにも zig build ひとつでビルドできることを目標としている
  • 1.0 の遅延は、後方互換性 を性急に約束しないための選択であり、501(c)(3) の非営利構造のおかげで長期的な改善に集中できる
  • Zig Software Foundation は 2024 年に 67 万ドル の収入を得ており、多様な支援構造を備え、CI の動作を優先して GitHub から Codeberg へ移行した
  • issue とプルリクエストには no LLM, no AI ポリシーを適用しており、AI による貢献はレビュー時間とメンタリングを損ない、負の価値になると見ている

Zig の出発点と言語設計

  • 誕生の背景

    • Andrew Kelley は デジタルオーディオワークステーション を作るために JavaScript、Go、Rust、C++ を順に試したが、望むユーザー体験を作るにはそれぞれ限界があったと見ている
    • JavaScript はブラウザ内では高水準すぎて、コンピュータの能力を十分に活用しにくいと判断した
    • Go は C ライブラリとの相互運用性がよくなく、オーディオのように決められた時間内に処理を終える必要があるリアルタイム処理では、ガベージコレクタ がグリッチやスキップを生む可能性があり不向きだと見ていた
    • Rust は 1.0 前の時点ではルールを満たすのが難しく、小さな変更でもコンパイルエラーの連鎖を引き起こし、フォントレンダリングを 1 か月かけて合わせた後も、それ以上進めるのが難しいと感じた
    • C++ は当初こそ生産的だったが、小さなタイプミスやミスがメモリ破損バグにつながり、数週間にわたってデバッグしなければならず、C++ コンパイラと C リンカを使う「C スタイル C++」でも footgun の問題は残ると見ていた
    • Zig の出発点は、ツールチェーンが許す範囲ではなく、コンピュータが本質的にできること を基準に、ユーザー体験を妥協しないという視点だった

  • C を置き換えられると考える理由

    • Zig は C の力を捨てることなく、C の欠陥と弱点を改善するため、C より優れている と見ている
    • C を置き換えようとした他の試みは、C が持つ何かを手放していたが、Zig は C ができることをすべて行いながら footgun を減らし、デバッグ可能性を高める
    • C では signed integer には最適化向けの整数しかなく、unsigned integer には wraparound の意味しかないが、Zig では signed/unsigned の両方で wraparound を許すか、overflow しない保証を選べるため、C よりもさらに「C らしい」と表現されている
    • オペレーティングシステムカーネル、組み込み機器、ビデオゲーム、WebAssembly など、どこでも再利用できるコードを書けなければ C は置き換えられず、Zig が C レベルの機能と安定性を提供できれば、性能が高くバグの少ない方が選ばれると見ている

  • Rust との違い

    • Rust と Zig の核心的な違いは 型システム にある
    • Rust では、関数の引数が clone をサポートするか、どのインターフェースをサポートするか、どの型を渡せるかといったルールをメタ言語で記述する必要がある
    • Zig では、そのような仕組みなしに具体的な型を渡すか、C++ テンプレートのように動作するジェネリック型を渡す
    • Rust のコードには型システムによる保証がより多く、Zig のコードには読みやすさと単純さがより大きいというトレードオフがある
    • Rust は C++ に近い RAII スタイルへとつながり、オブジェクトが別のオブジェクトを参照し、参照カウントが 0 になると自動的に解体される方向が自然である
    • Zig では アロケータ がはるかに明示的であり、参照カウントも可能だが、そのコードは明示的に書く必要がある
    • Zig では、アプリケーションに合わせたメモリ割り当て方式をよく使い、arena allocator で割り当てをまとめて一度に捨てたり、汎用アロケータをオブジェクト指向的なアプローチに使ったり、特定用途向けの混合方式を作ったりできる
    • CPU に何をしてほしいのかを考え、そのまま実行させるコードを書くやり方は、Rust よりも Zig の方が自然だと見ている

  • キラー機能とツールチェーン

    • Zig のキラー機能は ツールチェーン である
    • システム依存のないソフトウェア群であり、どのオペレーティングシステム上でも動作し、どのオペレーティングシステム向けにもコードをビルドできる
    • プロジェクトをハックしやすいかどうかは、README で多数のシステムパッケージをインストールする必要があるか、OS ごとに手順が異なるか、環境構築のためにいくつコマンドを実行しなければならないか、Docker や特定のハードウェアが必要かで判断できる
    • 最良の基準は 1 行、1 依存、誰にでも常に動く ことであり、Zig プロジェクトの README にあるビルド手順は zig build ひとつで十分であるべきだ

  • 言語ルールと IO インターフェース

    • 未使用変数をコンパイルエラーとして扱うルールは、大規模なリファクタリングでバグを見つけて時間を節約でき、変数を捨てるコメントを追加するコストは大きくないと見ている
    • ZLS チームのエディタ支援により、設定を有効にすると未使用変数を自動で discard し、再び使うようになれば discard を削除できる
    • 新しい IO reader / IO writer インターフェースは、画像読み込みライブラリやデータ形式のシリアライズコードのような再利用可能コードを一度書くための抽象化である
    • 消費するデータには reader、出力するデータには writer を引数として受け取り、パッケージとして分離し、複数のアプリケーションで同じロジックを使うことを目標としている
    • 抽象化レイヤーの下で読み書きが行われると、コンパイラがロジックを把握して最適化しにくくなり、性能を失う可能性がある
    • インターフェース内にバッファを含める設計が、コンパイラに良いコードを生成させつつ再利用性も達成できる最適点だと見ている

ユースケース、1.0、LLVM以後の方向性

  • 実際のユースケース

    • Zigは、コンピュータを完全に制御し、性能とメモリ使用を最大限に引き出し、説得力のあるユーザー体験を作りたいときに使う言語として提示されている
    • GhosttyはMitchell Hashimotoが作ったターミナルエミュレータで、コード品質、コミュニティ運営、ファズテストの面で優れたプロジェクトと評価されている
    • TigerBeetleは金融トランザクション向けデータベースで、PostgreSQLのようなリレーショナルデータベースの上にOLTPを載せる戦略とは異なり、特定用途向けデータベースを作っており、そのような戦略より「1000倍速い」と表現されている
    • TigerBeetleは実行時に今後使うすべてのメモリをあらかじめ割り当て、その後は動的割り当てを行わないため、レイテンシを予測可能かつ一貫して維持できる
    • BunはJavaScriptCoreと複数のC++ライブラリを使うJavaScriptエンジンで、グルーコードはZigで書かれている
    • Bunは最近Anthropicに売却されたと認識しており、その結果、AI用途でZigを使おうとする人が増えたと見ている
    • Uberは、Goコードが依存するCコードを一緒にクロスコンパイルするためにZigccをCコンパイラとして使い、ARM64向けビルドに活用している

  • 1.0が遅れている理由

    • Zigは10年が過ぎても1.0がないが、1.0は本質的に後方互換性の約束であり、プロジェクトごとに意味が異なると見ている
    • Goは1.0以降長いあいだ言語に手を入れず、Rustは1.0を比較的早く付けたが、エディションを通じて後方互換性を維持しつつ言語をかなり変えられたと比較している
    • Zig Software Foundationはスタートアップではなく501(c)(3)非営利団体なので、投資家からの圧力、売却、イグジット計画がなく、長期的に改善する時間がある
    • 1.0を出すときには、急いで固定した悪い決定に縛られない「妥協のない愛情の産物」になってほしいと考えている
    • 「worse is better」については、その表現自体が言語的におかしいと見ており、Zigはmore with lessを追求している
    • 複雑さの少ないcomptime機能から大きな効用を得て、1つのフラグだけでまったく異なるOSやアーキテクチャ向けにコンパイルできるツールチェーンを志向している
    • 1.0が出れば採用が急増するのは間違いないと見ているが、目標は今後50年のための言語を作ることだ
    • upcoming 0.16 リリースで、こうした選択の成果が見え始めるだろうと見ている

  • LLVMから離れる理由

    • LLVMから離れる理由は、中核製品に対する中核依存を避けるべきだという判断によるものだ
    • 10人対戦のアーケードゲーム Killer Queen では、開発者が物理エンジンにUnityを使っていたため、物理エンジンの小さな変更やバグ修正だけでも対戦プレイの感覚が変わってしまい、新しいUnityバージョンへ更新できなくなった状況を例に挙げている
    • 中核製品に対する依存を置いたことが失敗だったと見ており、ZigもLLVMに関してそれを正していく過程にあると見ている
    • LLVMは「自転車の補助輪」にたとえられており、Zigを10年以上作る中でコンパイラ開発についてより多くを学び、今では補助輪を外してLLVMと競争できると見ている
    • 独自のx86バックエンドでは、大規模な100万行コードベースでも、変更後50ms以下で新しいバイナリを得られる増分コンパイルが可能だ

  • 名前と学習パス

    • Zigという名前は、「Zig programming language」の検索結果が0件になる短い単語を探していて、Pythonスクリプトでランダムな単語を出力している途中で選んだ名前だ
    • マスコットのイグアナは「ziguana」と呼ばれている
    • 初心者にはZiglingsを強く勧めている
    • Ziglingsは、ほぼ動くコードに問題が入っており、壊れたプログラムを直しながら新しい言語機能を学ぶ一連の練習で構成されている
    • CからZigへの移行はとくにスムーズで、CでできることはすべてZigでもでき、footgunも少ない
    • Cでsegmentation faultが起きると、通常は「segmentation fault」以外ほとんど何も表示されず、デバッガを使う能力に頼るしかないが、Zigではコードの各行を指し示す完全なスタックトレースを受け取れる
    • Zigを最初のプログラミング言語として学ぶべきかは人によるが、コンピュータがどう動くのかを学びたい人にとっては、CPUとメモリを学べる良い言語だと見ている

財団運営、ガバナンス、プラットフォーム選択

  • 財政とスポンサー構造

    • 2024年のZig Software Foundationの総収入は67万ドル
    • 収入源は個人スポンサーや複数企業からの寄付で多様化されており、単一の主体が開発方針を強制できない構造になっている
    • 特定のスポンサーが「これをやれ」と要求してきても断ることができ、そのスポンサーが資金提供を打ち切っても存続できると見ている
    • スポンサーはバグトラッカーへの参加、プルリクエストの提出、開発チャンネルでの対話のように、他の人と同じ方法でのみ影響を与えられ、別個の秘密の高優先度チャンネルは存在しない
    • Andrew Kelleyの年俸は15万4千ドルで、最初の理事会で、この非営利団体が設立された都市のシニアソフトウェアエンジニアの年収中央値を基準に決めたという
    • 財団には従業員1名と、フルタイムで報酬を受ける契約者が約5名おり、前年度収入の**91%**がプロジェクト作業を行う契約者に支払われている
    • 条件なしの1億ドルの提案については、受け取ることはできるが成長には使わず、銀行に預けて100年間資金調達しなくて済むようにすると答えている
    • 現在5人のチームを管理しており、10人を超えると負担が大きくなる可能性があり、100人規模の組織の管理者になるつもりはないと明かしている

  • 501(c)(3)と透明性

    • 501(c)(3) は501(c)(6)とは異なるものだと区別している
    • 501(c)(6)はビジネスリーグであり、Rust FoundationはAmazon、Netflix、Microsoft、Metaのような企業がRustの成功に共同の利害関係を持って寄付する形として言及されている
    • 501(c)(3)では政府へのロビー活動は認められず、事業者の利害ではなく、ミッションステートメントのためだけに存在する
    • 収入と支出を詳細に公開するブログ記事は義務ではなく自発的な透明性であり、指標が良好なため信頼や資金調達にも役立つと考えている

  • GitHubとソーシャルメディアを離れた理由

    • RedditとTwitterを離れた理由は、それらのサイトに投稿することがSlashdotやDiggに投稿するのと同じように次第に関連性が低くなっていき、ソフトウェアエンジニアとしてマーケティングに使う時間を最小化したかったためだという
    • 何が見えるかをアルゴリズムが制御したり、荒らしとやり取りしたりするソーシャルメディアよりも、対面イベントやmeetupにより集中するほうが、コミュニティ成長へのより良い投資だと見ている
    • 2025年末にZigのメインリポジトリをGitHubからCodebergへ移した理由は、GitHubが継続的インテグレーションの結果をもはやきちんと提供しなくなり、「単純に動作しなかった」からだという
    • Codebergへ移行した後、継続的インテグレーションサーバーは再び動作するようになった
    • GitHub Sponsorsを離れることは収入源を失う可能性があるため難しい選択だったが、ソフトウェアを書くにはCIが動くことが最優先だと判断した
    • GitHubを離れた後も、財政的には「まったく問題ない」と表現している
    • ZigはMITライセンスのソフトウェアであり、ソフトウェア世界への無条件の寄付で、スポンサー支援もまた無条件の寄付だと見ている
    • Codebergを選んだ理由は、GitHubと本質的に似ていて移行が容易だったこと、そしてドイツの非営利団体だからだという
    • コードフォージはプロジェクトのマーケティング手段ではなく、人々はGitHubやCodebergではなく、発表、meetup、YouTube動画、Zigday meetupグループのような場所でこの言語を知るのだと見ている

  • BDFLと長期ガバナンス

    • ソフトウェアプロジェクトは、階層的統制と民主的手続きのどちらかを選ばなければならないことが多く、多くのプロジェクトが単純さゆえにBDFL方式を採用している
    • 一人が統制するなら、その人はあらゆることを理解し、プロジェクトに対する一貫したビジョンを持つ責任を負う
    • 委員会では、それぞれ有効な異なるユースケースやビジョンが衝突することがあり、2つのユースケースを同時に満たす単一の設計がない場合、妥協がより悪い製品につながる可能性がある
    • Andrew Kelleyが去ったとしても、ソフトウェアエンジニアリングの観点では同僚たちが非常に有能なので、プロジェクト運営を引き継げると見ている
    • 組織と財団の政治的観点では、まだやるべきことが残っており、金が流れるシステムは腐敗するという見方から、金の影響に抵抗しようとする強い階層的リーダーシップが現在は必要だと考えている
    • 一人の強いリーダーがすべてを統制する方式は持続可能ではないため、長期的な持続可能性のためには民主主義が必要だが、金の影響で時間とともに腐敗しないよう設計することが課題だとしている

  • 成功基準

    • Zigの成功は、ある観点ではすでに達成されている
    • 多様な収入源があるため単一主体から財政的に独立しており、満足して使い続けるユーザーがいて、毎年およそ2回リリースし、継続的に改善している
    • 別の観点では、より多くの採用を望んでおり、成功の一つの尺度はGoやRust並みの採用だとしている
    • 商用採用は企業寄付を受けられるため有用だが、企業寄付についても多様性を維持できるよう注意する必要がある
    • 一般的に有用なものを作れば企業にも有用になり、人々がZigをAIに使う姿にもその点が表れていると見ている

AIポリシー、開発ツール、プログラミングの未来

  • no LLM, no AI 貢献ポリシー

    • Zig はイシューとプルリクエストに対して厳格な no LLM, no AI ポリシーを設けている
    • AI による貢献は「相変わらずゴミ」であり、価値がないだけでなく、レビュー時間を奪って負の価値を生むと見ている
    • 現在オープンなプルリクエストが 200 件以上あり、小さな開発チームと多くの貢献者の間でレビュー時間がボトルネックになっている
    • AI で作られた貢献は、数回レビューしたあとに貢献者が内容を理解しておらず、レビューのフィードバックをチャットに貼り付けて、返ってきた回答を自分の言葉であるかのように取り繕うパターンが見えると考えている
    • コードレビューと貢献を受け入れる中核的な理由はメンターシップであり、貢献者が後にコアチームメンバーになったり、より価値の高い貢献者へ成長したりするよう支援することが目標である
    • 「contributor poker」は、限られた時間を誰に投資すればより良いプログラマーや貢献者に育つかを判断する過程である
    • AI を使う人は常に投資価値の低い単発の貢献者カテゴリに属し、学ぶこともなく、コアチームになる可能性もないと見ている
    • Zig プロジェクトは教育プロジェクトでもあり、学生に指導と教育を提供することがミッションの一部である
    • 「良い AI PR だけを許可する」なら判断者が必要だが、全面禁止は執行しやすいポリシーである
    • AI 生成かどうかの検出は常に容易ではなく、一部は入り込んでいる可能性も認めているが、多くのプルリクエストをレビューしていると、フィードバックを受けたときの振る舞いが人間のものではないと明確になる場合がある

  • MIT ライセンスと AI 学習

    • Zig のコードベースはMIT ライセンスであり、ソフトウェアライセンスに不慣れな人にとっては、実質的にパブリックドメインに近い
    • ほぼあらゆる用途に使え、コードをコピーするときはライセンスを再掲する必要があり、保証はなく、問題が起きても Zig 側に責任を問うことはできない
    • 大企業が Zig のコードを AI 学習に使うことは可能だが、Zig に AI が貢献することは禁止している点は皮肉である
    • Zig は世界に与える無条件の贈り物だという考えを強く持っており、AI 学習に使われても構わないと見ている
    • LLM が Python や JavaScript より Zig のコードで苦戦するかどうかは、本人はあまり直接試していないが、Mitchell Hashimoto は Ghostty で AI コーディングを広範に使っているという
    • Rocker というスクリーンネームの人物は、Zig で AI がよりうまく動くようにするツールを作り、成功を収めたという

  • バイブコーディングとプログラミングの未来

    • プロジェクトを長く続けながら技術を身につけ、問題を解決した内容を読むことは想像力を刺激し、自分なら何を作れるかを考えさせ、何かを教え、感情的なつながりも生む
    • 「このバージョンの Claude やあのバージョンの OpenAI を使ったら驚くほどよくできた」といったバイブコーディングブログは、インスピレーションを与えないと見ている
    • ソフトウェア品質の基準は「バグがなくて驚くべき」ではなく、妥協のない完全さであるべきだと強調している
    • Richard Feldman との非公開通話でバイブコーディングを試してみて、技術そのものは根本的に興味深いと見ている
    • ただし、およそ 4 社ほどの企業が中央集権的に支配し、モデルとその動作に完全な統制権を持っている点には強い拒否感を抱いている
    • 自分のコンピューターと電力を使ってコードを書くやり方から、ネットワークの向こう側にある他人のコンピューターでクローズドソースのプログラミングを月額サブスクリプションで使うやり方へ移行したいとは思わないという
    • 月300ドルを払っている人もいるが、そうした提案は本人には狂っているように思えると述べている
    • 10 年後、20 年後でも人間は引き続きコードを書いており、コーディングは楽しく、少なくとも趣味としては常に残ると見ている
    • 携帯電話やコンピューターで最も優れたアプリは、人々が余暇に趣味で作ったアプリであり、自由・オープンソースソフトウェアや自分のデバイスの所有者でありたいという欲求は消えないと見ている

  • 編集環境とリファクタリングツール

    • Zig の文法が変わってもコードを継続して編集できる回復力のある作業環境が必要である
    • tree-sitter や言語サーバーのような高度なツールは、安定した構文木や安定した言語を前提としているため、言語が壊れると一緒に壊れる可能性がある
    • 個人的に Zig を書くときは、高度に整った環境よりもターミナルと Vim を使っており、Vim は変化に非常に強い
    • ZLS は Zig language server の略で、Zig のための Language Server Protocol 実装であり、Zig Software Foundation が運営していないサードパーティープロジェクトである
    • Zig のウェブサイトは JetBrains 製品を推奨しているが、Andrew Kelley は JetBrains 製品がクローズドソースであるため使ったことがない
    • 過去に JetBrains や Eclipse が提供していた、関数の抽出、関数パラメーターの並べ替え、グローバルな名前変更のような高水準のリファクタリングツールを高く評価していた
    • 長期的には、型情報や他の手がかりをもとに大きな変更を行えるクエリ言語のようなリファクタリングツールを望んでいる
    • 変数名の変更のようにスコープが明確な作業は、信頼できるツールが処理すればコミットを作ってレビューしなくてもよいほど、結果を 100% 確信できる
    • 同じ作業を AI ツールに依頼すると依然としてコードをレビューしなければならないため、信頼できるリファクタリングツールよりも時間がかかり、より悪い選択になる

個人的な動機とオープンソース観

  • Zigを続ける動機と難しさ

    • Zigに取り組む動機は、コンピュータを愛し、コンピュータが人に奉仕するものになってほしいという思いから来ている
    • Zigは、優れたプログラミング言語とツールチェーンがそのような結果につながるという楽観的な贈り物として表現されている
    • ユーザーを満足させ、強力なユーザー体験を作ることに大きな満足を感じており、良いソフトウェアを作る感覚を、音楽家がステージで演奏するときに得る感覚になぞらえている
    • 非営利団体の運営に必要な税金と書類業務が最も大変な部分として挙げられている
    • 法的に問題なく運営し、大口の寄付を受けるために不可欠だが、現在はその仕事をAndrew Kelleyが担っている
    • ある日は会計業務をし、ある日はプログラミングをしており、プログラミングをする日を良い日だと考えている
    • Zig 0.15のIO reader / IO writerインターフェース変更は、最適解を探し、APIを作ってテストし、他のプログラミング言語と比較して新しい解決策を見つけた結果だったが、その後6か月にわたって標準ライブラリとエコシステムのプロジェクトを修正しなければならなかった

  • バーンアウトと助言

    • バーンアウトは、多くの努力を注いでいるのに、その努力に対する見返りがあまり見えないときに生じると考えている
    • Andrew Kelleyは多くの努力を注いでいるが、満足しているユーザー、Zigのリリース、リリースノート、改善点といった報いを見られるため、概ねバーンアウトから守られている
    • IO変更のように、報いが何か月も遅れてやってくる作業はバーンアウトのように感じられることもあるが、最終的に報いが来ればよくなる
    • バーンアウトを経験している人には、まず運動、十分な睡眠、健康的な食事を心がけるよう勧めている
    • 自分の仕事が嫌いだったり、会社が世の中に価値あることをしていないと感じているのに、一生懸命働かなければならないなら、バーンアウトの条件がそろう
    • その場合は別の仕事を探したり、起業のように自分の仕事を作る難しい道も一つの選択肢であり、「魂のない企業」で働いているなら午後5時に帰宅して別のことをし、働きすぎないよう助言している

  • 尊敬するプロジェクトとブラウザの多様性

    • 尊敬するプロジェクトの一つ目としてLinuxを挙げている
    • 独占的なOSしかない世界ははるかに悪いものになっていただろうし、Linuxは自由・オープンソースの開発者だけでなく、世界中の国や企業が無料で事業を構築できるようにし、経済的にも良い影響を与えたと評価している
    • 二つ目はBlenderで、プロ向けに使われ、多くの資金と開発人員を持つ企業と競争しながら勝っているオープンソースプロジェクトであり、非営利団体でもある点を高く評価している
    • 三つ目はVLCで、以前FFmpegに貢献していたとき、VLCや依存ライブラリに貢献した人のVideoLAN Dev Daysへの旅費をVLCの組織が負担していたことを振り返っている
    • Firefoxを使う理由は、ブラウザの多様性に対する懸念があるためだ
    • MicrosoftがInternet Explorerを終了した後、主要ブラウザとして残ったのはChromium、Safari、Firefoxだけであり、Chromiumが市場の大半を占めているのはWebにとって問題だと見ている
    • 最近のMozillaには満足しておらず、非営利団体であるにもかかわらず腐敗が多く、ユーザーとの方向性が合っていない事例のように感じると述べている
    • ChromiumはGoogle、SafariはApple、Firefoxは下降傾向に見え、代替が不足しており、新しいブラウザプロジェクトが成熟するまで何をすべきか分からないと見ている

  • 2015年に戻ってもZigを始めるか

    • 2015年に戻っても必ずZigを始めると答えている
    • OkCupidを辞めてZigをフルタイムで始めた日は、その後の人生の軌跡を基準にすれば人生最高の日だった
    • Zigは深い充足感、独立性、自己価値感、社会に貢献しているという感覚を与えてくれた
    • 自分は基本的に雇われにくい人間だと感じており、幸せになるには自分自身のボスになる必要があり、その状態になってから幸福を得られた

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見
  • Zig Software Foundationの外にいる人たちにも、Andrewとコアチームがプロジェクトを前に進めるときに持っている情熱と哲学を知ってほしい
    JetBrainsがインタビューをより刺激的にしてバズを狙ったとしても責められないが、結果として最良の質問はZig対Rustではなく、非営利、持続可能性、愛情で作るZigに関するものだった
    Andrewがプロジェクトの裏で静かに燃えている人間的な側面を世界にうまく見せたと思う
    • 正直、JetBrainsがそこまで刺激的な方向に誘導したようにも見えない
      動画は、Zigをかなり使ったことがある人よりも、Zigに興味がある人たちやプロジェクト運営に関心のある人たちをずっと強く意識していたように見えるし、その観客が知っていそうな話題を避けずに取り上げただけだ
      インタビュアーも火をつけるのではなく、Andrewの言葉が自然に表れるようにしていて、この種のインタビューとしては非常に思慮深かった
      ただ、字幕として入れると決めた単語を見て笑ってはしまった。Zigには興味があるがLinuxや抽象化の定義を知らない人がどれほどいるのかは分からない
      全体として、Zigの見せ方としても、JetBrainsのマーケティングチームに対する印象としても、とても好意的だった
  • Andrewが中盤あたりで、ZigとAIの利用を助けるために私が作ったツールに触れていたが、試してみたい人のために言うと、そのツールはzigdoc: github.com/rockorager/zigdoc
    基本的には、Zig標準ライブラリとビルドグラフ内で見つかった依存関係のドキュメントをコマンドラインで見るためのツールだ
  • 動画の最後の数秒でAndrewが幸せだと言う場面が本当によかった
  • 「妥協のない愛情労働」という表現がぴったりだ
    1.0を急がないというフレーミングは魅力的だが、Zigはエコシステムの変化による揺れを引き受けてくれるユーザーがいるという意味で恵まれている
  • 組み込み分野では、ここ数年ずっとCが主力ツールだった
    C++ではなく、ただのCだった
    次の組み込みプロジェクトをZigにするかRustにするかずっと悩んでいたが、今は「その時が来た」という感じがする
    このインタビューは私にとって決定打になるかもしれないし、そこには強く共感できる全体的なトーンがある
  • ZigがLLVMから離れようとしている理由についての回答が本当によかった
    Zigの中核機能に当たるため、チームがより多くのコントロールを持つべき部分をうまく扱っていた