Zigプロジェクトはどこにも行かない

Zigプロジェクトはどこにも行かない

Zigはプログラミング言語として進化を続けています。残念ながら、その管理体制は、実際にそれを使いたい人々にとって悪い選択肢にすることにますます固執しているように見えます。

Zigは魅力的なプログラミング言語です。その設計には真に優れたアイデアが含まれており、技術的な野心は目覚ましく、真剣なシステムプログラミングツールチェーンを構築するために長年取り組んできた才能ある開発者を引きつけてきました。それにもかかわらず、それを推奨することはますます困難になっています。

問題は、Zigの管理が不十分であるように見えることです。

過去1年間、プロジェクトは一連の決定を下しましたが、これらは個々にはオープンソース開発に関する通常の意見の相違のように見えるかもしれませんが、全体として深く懸念されるパターンを明らかにしています。

言語は、安定性に対する具体的なコミットメントなしに互換性を破壊し続けています。その貢献ポリシーは、それ以外では正当なエンジニアリングワークフローを排除しています。最も著名なユーザーの1社は言語を放棄しました。それに対して、公然たる敵意をもって迎えられました。また、GitHubから離れたことは、成熟した開発プラットフォームを、信頼性の問題に悩まされる、より小さく、証明されていないサービスに置き換えました。その運営者はホストされたプロジェクトに独自の哲学的選好をますます課しています。

繰り返されるテーマは、Zigのメンテナーが、ソフトウェアを開発したい人々にとって実用的なツールにするよりも、ソフトウェアがどのように開発されるべきかという彼らのビジョンを強制することに、より関心があるように見えるということです。そして、それはプログラミング言語にとって深刻な問題です。

Zigは永久に未完成であり、そのユーザーが代償を払う

Zigは10年以上開発されています。安定した1.0リリースへの確実な日付なしに、バージョン0.xのままです。

長い開発サイクルや1.0未満のバージョン番号に本質的に問題はありません。多くの有用なソフトウェアは、いわゆる0verの下で動作しています。esbuildはその顕著な例であり、メジャーバージョンが0のままであるにもかかわらず、堅牢で妥協のない品質とわずかな破壊性を持っています。

しかし、Zigはプログラミング言語であり、バンドラーではありません。

プログラミング言語はインフラストラクチャです。開発者は、構文、標準ライブラリ、コンパイラ、ビルドツールに対してアプリケーションやライブラリを記述し、これらのインターフェースが、リリースから次のリリースにかけて、周囲のエコシステムのどれだけが利用可能であり続けるかを決定します。Zigでは、それらは永遠に変化しているように見え、作者は互換性の破壊にほぼ執着しています。

0.15.1リリースノートを考えてみてください。I/Oインターフェースと標準ライブラリに大幅な変更があり、愛称で「Writergate」と呼ばれています。コンパイラを書いている人にとっては十分に面白いかもしれませんが、コードがコンパイルされなくなった人を書いている人にとっては、おそらくそれほど面白くないでしょう。バージョン0.16はその移行を継続し、2026年10月にリリースされた0.17.0は、言語とそのツールにさらなる変更をもたらしました。Zigのメンテナーは互換性を破壊することを楽しんでいるかのようです。そうでなければ、彼らはそれに快適であるように見えます。

したがって、Zigのアップグレードは、単に新しいコンパイラをインストールするだけではないことがよくあります。それはしばしば、既存のコードの大部分を書き直し、依存関係を更新し、ツールやライブラリが追いつくのを待つことを意味します。Zigがこれらの変更を公然と文書化しているという事実は、負担を軽減しません。

これらの変更の一部は設計を改善するかもしれませんが、それは論点ではありません。すべての変更は、すでに言語の上に何かを構築したすべての人に作業を作成します。そして10年以上経った今、これがいつ止まり、真剣にZigコードを書き始めることができるかを尋ねるのは、それ以上ないほど合理的です1。

メンテナーには1.0へのロードマップがありますが、開発者には、依存しているインターフェースがいつ変更されなくなるかを期待できるかについての意味のある手がかりを与えません。それはさらに10年かかるかもしれません。

それは彼らに選択肢を残します。プロジェクトを古いコンパイラバージョンでフリーズするか、上流に追いつくために繰り返しエンジニアリング作業を費やすかです。プロジェクトが2つの悪い選択肢を提供する場合、何かうまくいっていないことがわかります。

プログラミング言語は、結果なしに永続的な実験であり続けることはできません。ある時点で、実験は利点ではなくなり、言語を使用するすべての人に負担をかけ始めます。この段階で、私たちはその点をはるかに過ぎています。

Zigの不安定さは単なる不便ではありません。それは、言語に依存することが依然として困難である中心的な理由の1つです。

そして、それはメンテナーの貢献者に対する態度をさらに擁護しにくくします。

コードを受け入れるのではなく、教訓を教えたいプロジェクト

Zigは、例外的に制限の厳しいAI貢献ポリシーを持っています。

AI生成コードなし。AI支援編集なし。AI支援翻訳なし。LLMとブレインストーミングして結果を共有することもなし。バグを見つけるためにLLMを使用することさえなし。本当に？

レビューされていないAIのゴミをプルリクエストに1000行ダンプすることと、コンパイラの不慣れな部分を理解するためにアシスタントを使用すること、バグを見つけること、または修正を実装するのを助けることの間には、明白な違いがあります。そして、Zigのポリシーは、2つを区別するためにほとんど努力していません。

Contributor Poker and Zig's AI Banで、メンテナーは彼らの哲学を説明しています。彼らは、Zigを深く理解し、長期間関与し続ける貢献者に投資したいと考えています。低品質のプルリクエストのレビューはコストがかかり、AIはその問題を悪化させたと言われています。

それで結構です。誰もゴミをレビューしたくありません。しかし、そこで示唆に富む部分があります：

「あなたはカードではなく、人に賭ける。」

この記事は、最初のプルリクエストの内容よりも、適切な貢献者に投資することが重要であると主張しています。これらのツールを使用しない人々と比較して、それらのツールを使用する有能なAI支援貢献者が存在することを認めてさえいますが、それらを魅力のない賭けと見なしています。

それが何を意味するかを考えてみましょう。有用な貢献は、それが間違っている、十分にテストされていない、または保守不可能であるという理由ではなく、その作成者がそれを作成するために間違ったツールを使用したという理由で拒否される可能性があります（そして実際に拒否されなければなりません）。プロジェクトはもはや貢献だけを判断していません。それは貢献者の開発プロセスを判断しています。メリットだけではもはや十分ではありません。

そして明らかに、貢献者は、何かを修正する特権を得るために、Zigの内部に深く精通することが期待されています。なぜ？

誰もがコンパイラエンジニアになりたいわけではありません。一部の人々は、自身のソフトウェアを構築しようとしているときにバグに遭遇し、それを修正したいだけです。それは、あなたがZigで今後10年間働くつもりであろうと、二度と触れないつもりであろうと、完全に正当な貢献です。

本当にばかげているのは、この態度がZigの永続的な不安定さとどのように衝突するかです。言語、標準ライブラリ、ビルドシステムは常に変化しています。開発者は新しいインターフェースを学び、プロジェクトを移行し、依存関係を更新し、次のリリースが到着したときにその演習を繰り返す必要があります。

そして、この継続的な再学習演習を課しながら、Zigのメンテナーは、それを容易にする可能性のある特定のツールが許容できないと決定しました。

あなたは言語を理解しなければなりません。その変更に追いつかなければなりません。内部を学ばなければなりません。そして、承認された方法で行う必要があります。あなたのZigコードを維持することがソフトウェア開発になるのはいつで、Zigプロジェクトから割り当てられた宿題になるのはいつ止まるのでしょうか？

そして、これはZig自身の約束にどのように応えているのでしょうか。「プログラミング言語の知識をデバッグするのではなく、アプリケーションのデバッグに集中する」？

私はもともと、まさにその約束のためにZigに興味を持ちました。Rustのコードを見るたびに、博士号が必要だと感じていました。Zigは率直で理解しやすかったです。それは、彼らが壊すことを壊すために愛するようになるずっと前のことです。

ほとんどの開発者は、コンパイラのメンテナーとの継続的な教育関係を望んでいるからプログラミング言語を使用しているのではありません。彼らは単に、適切なツールを使って物事を成し遂げたいだけです。

貢献者に、彼らの仕事の理解と責任を要求することは完全に合理的です。その理解をどのように獲得するかを指示し、処方することははるかに合理的ではありません。LLMがそれを生成するのを助けたからといって、コンパイラの改善が無価値になるわけではありません。そのような根拠で有用な作業を拒否することは、技術的な厳密さではありません。

それはドグマです。

BunはZigを去った。そしてZigの反応は恥ずべきものだった。

長年、BunはZigの事実上の無料広告でした。Zigで書かれた高性能JavaScriptランタイムは、かなりの採用を集め、言語が本番用のソフトウェアに使用できることを示しました。Bunは誇らしげにZigの旗を掲げていました。Zigが永遠の破壊の深淵にますます沈んでいく間も、BunはZigをメジャー1として扱っていました。

その後、2026年7月に、BunはZigコードベースをRustで書き直したと発表しました。

Bunには正当な技術的理由がありました。そのチームは、特にJavaScriptのガベージコレクタとZigの手動メモリ管理との相互作用に関して、繰り返し発生するメモリ安全性問題を説明しました。Rustの所有権システムは、Bunのワークロードに価値のある保証を提供しました。

この目的のために、BunはZigコンパイラ自身の変更も維持していました。上流の貢献の摩擦がメンテナンスの負担を増大させていました。これはZigプロジェクトにとって警戒すべきことだったはずですが、聞き入れられませんでした。

最も著名なユーザーの1社が、かなりのエンジニアリングリソースと長年の言語への投資を持っていましたが、Zigを継続することはそれだけの価値がないと結論付けました。そして、まあ、公平です。誰もがZigを選ばなければならないわけでも、永久にコミットしなければならないわけでもありません。しかし、主要なユーザーが去るとき、おそらく理由を尋ねる価値があるか、この場合は理由を読むだけで十分です。代わりに、プロジェクトは驚くほど辛辣な公開攻撃で対応しました。

Bunの書き直しへの長い応答で、ZigのリーダーシップはBunの技術的議論に同意する以上のことをしました。投稿はBunのエンジニアリングプラクティス、管理、開発文化、ビジネス上の決定を批判しました。それは、関係が終わったことに財団が安堵したと述べ、Bunを負債（Zigプロジェクトがその気まぐれを正当化する際に特に好む用語）として扱いました。そしてこれらすべては、長年Zigを使用し、公に宣伝し、そのエコシステムに貢献し、その開発に多額の寄付をしたプロジェクトへの対応でした。

Bunの発表はZigに対して広く感謝的でした。Zigの応答は、感謝とは程遠いものでした。投稿は後に改訂され、初期のフレーミングにおける怨恨を認めました。それは何かですが、それは未熟さとプロジェクトメンテナーのソフトウェア開発のダイナミクスに対する深刻な理解不足を明らかにする損害を元に戻すものではありません。

Aプログラミング言語はユーザーを所有しません。

Bunは、メンテナーがその設計を信じていたからといって、Zigを使い続ける義務はありませんでした。また、Zigが好むエンジニアリング文化に従ってソフトウェアを開発する義務もありませんでした。そのニーズがRustによってより良く満たされるのであれば、それはBunの決定です。それを正当化する必要さえありませんでしたが、そうしたという事実は、Zigに対しては優雅さ、そして自身のユーザーに対しては成熟さを示しました。これらは、Zigプロジェクトが深刻に欠いているように見える2つの資質です。

そして、ZigのメンテナーがBunの技術的理由に同意しなかった場合、それをBunの背後にある人々や文化についての公開論争に変えることなく、その議論をすることができたでしょう。

これは、他のすべての人に特に懸念されるメッセージを送ります。Bunのような著名なプロジェクトが、去る際にこのような扱いを受けるのであれば、小さなプロジェクトはZigを批判したり、移動を決定したりしたときに何を期待すべきでしょうか？これは、プログラミング言語への信頼を築く方法とはかけ離れています。実際、それは人々がそれに依存することをためらわせるまさに方法です。ユーザーの1社が去ることを決めたからといって、公開の癇癪を起こすのを見るほど、プロジェクトのガバナンスに信頼を与えるものはありません。

Bunの移行だけでは、Zigが悪い言語であることを証明するものではありません。

しかし、ZigがBunを失った方法の扱いは、プロジェクトの管理について多くのことを物語っています。

Codebergはひどい選択だった

2025年11月、ZigはGitHubからCodebergへの移行を発表しました。

それ自体、GitHubを離れることは問題ではありません。GitHubにはそれ自身の多くの問題があり、ZigのGitHub Actionsに関する苦情は代替案を検討する正当な理由でした。問題は、Zigがどこに行ったかです。

Codebergは小規模な非営利Gitホスティングサービスです。また、私の経験では、イライラするほど信頼性が低いです。私は繰り返し接続の問題に遭遇したり、必要なときに利用できないことがわかりました。

そして、苦情を言っているのは私だけではありません。

CachyOSをGitHubからCodebergに移動することを提案したとき、CachyOSフォーラムの議論の参加者は次のように応答しました。

「Codebergは率直に言って、非常に不安定で、しばしば接続の問題が発生します。」

他の参加者も同様の懸念を提起し、ある人はCodebergが真剣なGitHubの代替として信頼されるほど成熟していないと主張しました。

これらは単なる逸話的なユーザーレポートです。しかし、それらは私の経験と一致しており、信頼性は、異常に要求の厳しいユーザーにのみ関係するような、あまり知られていない機能ではありません。開発プラットフォームの最低限の要件です。

ZigはGitHubに留まる必要はありませんでした。GitLabを選択したり、他の確立されたホスティングプロバイダーを評価したり、独自のForgejoインスタンスを実行したりすることもできました。それには技術的な知識があるかもしれませんが、明らかにその作業を引き受けることを好みませんでした。セルフホスティングには当然作業が伴います。しかし、自身のインフラストラクチャを制御することがそれほど重要なのであれば、おそらくそれは行う価値のある種類の作業でしょう。

代わりに、Zigは重要な開発インフラストラクチャを信頼性が疑わしいプロバイダーに移行し、それを進歩として売り込もうとしました。そして、信頼性の懸念は、最悪の部分でさえありません。

2026年7月、Codebergは「LLMからFLOSSコモンズを保護する」を発表し、特定のカテゴリのAIヘビーなプロジェクトを制限する決定を説明しました。

Codebergには、リソースを管理し、乱用を防ぎ、自動クローラーから自身を保護する権利があります。しかし、発表はそれだけでは終わりません。LLMベースの開発の正当性について広範な判断を下しています。その運営者は、LLMは責任あるオープンソースソフトウェア開発と互換性がないと明確に主張しており、そのポリシーはコードがどのように生成されたかに基づいてプロジェクトを除外する可能性があります。

これはGitホスティングプロバイダーにとってかなり異常な方向性です。別の開発者が「Codebergへの移行を後悔しています」で述べているように、懸念されるのは現在制限されているプロジェクトだけではありません。それは、ホスティングプロバイダーが、どの正当なソフトウェア開発の形態がプラットフォームに属するかを決定することに自身を任せているということです。

AIが好きかどうかに関わらず、ここに問題があることがわかります。Codebergは自身をフリー・アンド・オープンソースソフトウェアのホームと呼んでいますが、ますますどの種類のソフトウェア開発が歓迎されるべきかを決定することに関心があるようです。明らかに、コモンズは、誰もがそれを使用する方法に同意する限り、コモンズです。

A Gitフォージはコードをホストし、問題を管理し、コラボレーションを促進する必要があります。それは、妥当な制限を施行し、乱用を防ぐ必要があります。プロジェクトの開発哲学が十分に徳が高いかどうかについて判断する必要はありません。

Codebergの発表はZigの移行後に行われたため、メンテナーが当時何を知っていたかを確立するものではありません。しかし、それは間違いなく、後から見るとその選択をより良く見せるものではありません。

ZigはGitHubの問題を、私の経験では信頼性が低く、ますますソフトウェアの書き方についてポリシーを課すことに懸念しているホスティングプロバイダーという、異なる一連の問題と交換しました。

そして、プロジェクト自身のポリシーがその哲学と一致しているため、選択の唯一の理由が実用的な考慮事項であったとは信じがたいです。

寄付でさえ間違った種類になり得る

GitHub移行発表には、GitHub Sponsorsに関する特に奇妙な一節も含まれていました。

Zigの資金調達においてプラットフォームがどれほど重要であったかを認めた後、メンテナーは次のように書いています。

「GitHub SponsorsはZig Software Foundationの寄付収入の大部分を占めていますが、私たちはそれを負債と見なしています。」

そして、サポーターに、定期的な寄付をEvery.orgに移行するように求め、GitHub Sponsorsの特典の廃止を発表しました。ここでも尋ねなければなりません、なぜ？

Zigは主に寄付によって資金提供されています。人々は、開発者が言語で作業を続けられるように、自発的にプロジェクトにお金を寄付しています。そして今、人々がそれをサポートしてきたプラットフォームの1つが、明らかに負債なのですか？昨日は資産、今日は負債？

確かに、サードパーティのプラットフォームに依存することにはリスクが伴います。GitHub Sponsorsは明日、条件を変更する可能性があります。しかし、それは資金調達を多様化する理由であり、既存のチャネルを破棄する理由ではありません。なぜリポジトリをGitHubに読み取り専用ミラーとして残し、そこで寄付を受け取り続けないのですか？

メンテナーがGitHubを気に入らなくなったという理由だけで、すでにZigをサポートしている人々が支払い方法を変更する必要があるのはなぜですか？実際の開発は完全にCodebergで行うことができました。誰も問題、プルリクエスト、またはCIのためにGitHubを使用する必要はありませんでした。そして、GitHub Sponsorsを好む人々は、それを介して寄付を続けることができました。

資金調達を他の場所で統合したいという管理上の理由があったのかもしれません。しかし、発表は、両方のチャネルを維持することがなぜ受け入れられなかったのかを確立していません。メンテナーは既存のサポーターに感謝しましたが、文字通り寄付を拒否していたわけではありません。しかし、私はまだそのメッセージを驚くほど鈍感だと感じています。

あなたのプロジェクトが自発的な貢献に依存している場合、人々があなたをサポートすることをより不便にすることは、彼らが使用するプラットフォームを気に入らないという理由よりも良い説明を必要とするはずです。

GitHubに開発を依存しないことと、あなたにお金を与えようとしている人々にとって、その好みを不要な摩擦に変えることは別問題です。

再び、他のすべての人々がZigの原則に適応することが期待されています。

どこにも行かない

Zigは死んでいません。開発は続いており、コンパイラは改善され続けています。

しかし、技術的な進歩は成熟と同じではありません。互換性の破壊とプロジェクト管理の気まぐれについていくことが、ますます洗練されたプログラミング言語の何が良いのでしょうか？

パターンを見てください。ユーザーは不安定な言語に追いつくことが期待されています。貢献者は承認された方法で働くことが期待されています。著名な下流ユーザーがRustの方が適していると判断し、プロジェクトは公然と非難します。ホスティングプラットフォームが変更され、ドナーはそれに従うように求められます。

Zigのメンテナーは、他のすべての人々がプロジェクトに適応することを期待していますが、プロジェクトを他のすべての人々に適応させることには驚くほど意欲がありません。

間違いなく、彼らはZigを好きなように運営する権利があります。オープンソースは、メンテナーがすべての人に無制限のサポート、無料のコードレビュー、または永遠の後方互換性を負うことを意味するわけではありません。しかし、逆もまた同様です。ユーザーはメンテナーに時間、忠誠心、または彼らの哲学への同意を負う必要はありません。

開発者はソフトウェアを書きたいのであり、標準ライブラリAPIを移行するのに何時間も費やしたくありません。貢献者はバグを修正したいのであり、承認されたエンジニアリング学派への忠誠を証明したくありません。企業は、問題を解決する言語を求めており、ビジネスの実行方法についての講義を求めているのではありません。そしてドナーは、プロジェクトをサポートしたいのであり、GitHubとの論争に巻き込まれたくありません。

良いプロジェクト管理とは、妥協することです。時には、別のエレガントな再設計よりも安定性を優先することを意味します。時には、好ましい開発イデオロギーを共有しない人からの有用なパッチを受け入れることを意味します。時には、主要なユーザーが去るときにプライドを飲み込むことを意味します。そして時には、哲学的な声明をすることではなく、退屈で信頼性の高いインフラストラクチャを選択することを意味します。

Zigはそれ以外のことを何でもすることに固執しているようです。

これらのどれも避けられないものではありません。Zigは、はるかに信頼性の高い言語であり、はるかに扱いやすいプロジェクトになることで、技術的な野心を維持することができます。しかし、そのためにはメンテナーがユーザーのニーズを、管理されるべき不便以上のものとして扱い始める必要があります。

プロジェクトは言語設計を永遠に洗練し続けることができます。それは、良いエンジニアリングという彼ら自身の考え方を主張し続け、間違った種類の貢献を拒否し、彼らの世界観に一致するプラットフォームを選択することができます。

しかし、ある時点で、人々が使用できるプログラミング言語を構築したいのか、それともメンテナーがソフトウェアがどのように開発されるべきだと考えているかの継続的な実験を構築したいのかを決定する必要があります。

Zigは、メンテナーが言語に何を望むかを10年以上かけて考えてきました。おそらく、ユーザーが必要とするものに、もう少し気を配り始める時が来たのではないでしょうか。

それまで、Zigプロジェクトはどこにも行かないでしょう。

---

---

1. 比較として、Go 1.0は2012年3月にリリースされました。これは、2009年の公開デビューから約2年半後です。Rust 1.0は2015年5月に登場しました。これは、初期の公開開発から約5年後です。この点について、ご自由に解釈してください。

   ↩

---