世界を動かす技術を、日本語で。

Zig: すべてのパッケージ管理機能がコンパイラからビルドシステムに移動しました

2026年7月5日原文(ziglang.org)

概要

  • Zigのmainブランチ2026年の主な変更点をまとめた内容
  • パッケージ管理機能がコンパイラからビルドシステムへ移動
  • SPIR-Vバックエンドの大幅な改善と新機能追加
  • @bitCastの新しいセマンティクス導入とLLVMバックエンドの改良
  • 今後の課題や残タスク、コミュニティへの貢献呼びかけ

2026年6月30日 パッケージ管理機能のビルドシステム移行

  • パッケージ管理ロジック がコンパイラからビルドシステム(makerプロセス)へ完全移行
    • zig build, zig fetch, zig init, zig libc サブコマンドの担当移動
  • これまでコンパイラ実行ファイルに含まれていた機能が ソースコード形式 で配布
    • パッケージ取得ロジック、HTTPクライアント、TLS・暗号、Gitプロトコル、各種圧縮・解凍、build.zig.zonファイルの解析・検証
  • コンパイラの再ビルド不要 でパッケージ管理機能のパッチ適用が可能
  • maker実行ファイルは ReleaseSafeモード でビルド、ネットワーク時の安全性向上
  • ネットワーク・ファイルハッシュ用の暗号処理が ホストCPUの特殊命令 を活用可能
  • プロセス構成の変更により、ビルドサーバー導入時のプロセス管理が容易化
  • 互換性への影響はほぼなしだが、 実行ファイルサイズ4%縮小 や一部フラグ・環境変数の置き換えあり
    • --maker-opt → ZIG_DEBUG_MAKER
    • --zig-lib-dir → ZIG_LIB_DIR
  • Zig 0.17.0リリースまでの主なブロッカー
    • build server protocol MVP
    • ビルドスクリプトのパス依存性導入
    • zig build --watchのビルドスクリプト変更検知
    • カレントディレクトリ違いによるキャッシュミス
  • ZLSチームのTechatrix氏への感謝とスポンサー募集の案内

2026年6月26日 SPIR-Vバックエンド進捗

  • SPIR-Vバックエンド が最近のコンパイラ変更でビットロット化していたため、数週間かけて改善
  • Zigの型システムで表現できなかったSPIR-V型に対応する @SpirvTypeビルトイン 追加
    • Sampler, Image, SampledImage, RuntimeArrayなどへの対応例
  • 実行モード情報 が呼び出し規約に組み込まれ、OpExecutionMode命令の手動出力は禁止
    • spirv_task, spirv_mesh呼び出し規約追加
  • Capabilities/Extensions もCPU機能セットに基づく自動管理へ移行
    • OpCapability, OpExtensionの手動出力は禁止
  • コード生成のマルチスレッド化 を実現、dedup_types・prune_unusedパスの復活
  • .spvファイルを オブジェクトファイル として認識、複数ファイルのリンク対応
  • spirv64-vulkanターゲットのテスト通過率が10%近く向上(49%)
  • std.gpu → std.spirvへリネーム、SPIR-Vバックエンドの実用性向上
  • なお、多くのテストは未対応のまま
  • バグ報告をCodebergで歓迎

2026年6月25日 新@bitCastセマンティクスとLLVMバックエンド改善

  • LLVMバックエンドの整数型の格納方法 を最適化
    • 任意ビット幅整数型(例:u4, i13, u40)をSSA内のみbit-int型で扱い、メモリ格納時はABIサイズ型へ拡張
    • Clangの_BitInt(N)と同様の方式
  • @bitCastの問題点
    • 旧仕様はメモリを直接再解釈する定義で、挙動不明瞭かつバグの温床
    • LLVMバックエンドの仕様変更で@bitCastの実装に問題発生
  • 新しい@bitCastセマンティクス を全バックエンドで実装
    • 2024年の言語提案(#19755)に基づき、自己ホストx86_64バックエンドと同一仕様へ
    • Legalizeパスの活用で全バックエンドの実装容易化
    • 標準ライブラリやコンパイラ内部の@bitCast利用箇所も監査・修正
  • LLVM・Cバックエンド、comptime実行まで新仕様を適用
    • セマンティクスの違いによるCI修正もほぼ完了
  • 新@bitCastの具体的な挙動 や今後の詳細は別途解説予定

Hackerたちの意見

Zigの開発はすごく心温まる感じがする。

それに、作るのも結構楽しいよ。ブートローダーを作ったり、UEFIのことをやったり。Cでやるよりもずっと簡単だし。新しくてキラキラしてるし、学ぶのも楽しいから、余計に好きになっちゃう。

今の時代のZigについて言えるのは、ソフトウェア開発という職人技は死んでないし、LLMに取って代わられてもいないってこと。毎日LLMを使ってるけど、確かに多くの問題に対してはすごく優れてると思う。でも、LLMが作ったプログラミング言語は欲しくないな。プログラミング言語のコードの一行一行、決定、妥協、すべてが重要なんだ。雰囲気でデザインされたプログラミング言語なんて、絶対に失敗すると思う。どう表現すればいいかわからないけど、今まで見たモデルで、そう思わせるコードを生み出したものはないよ(Fableは確かに前のモデルよりは改善されてるけどね)。モデルには何も欲しいものがないし、意味のある意見も持ってない。言語の中で快適さと不快さがどう感じられるかなんてわからないし(GUIやCLIのインターフェースが十分な複雑さを持っている場合でも)。LLMからZigのような言語を得ることはできないし、単にZigをコピーすることになる。たとえそうだとしても、コピーは劣化版になるだろうね。(つまり、「LLMでコピーする」というのは、「LLMに仕様を書かせて、別のものがその仕様に基づいて言語を作る」ってことだと思ってる。ソースツリーをそのままcpするわけじゃないよ。)

長期的な目標はビルドシステムをWebAssembly VMに移行することだとどこかで読んだことがある。もしそうなら、すごいことだね。

それってビルドにどんな利点があるの?

どの言語も独自のパッケージシステムを作っているのを見るたびに、私たちがここでどれだけ損をしているかしか考えられない。唯一の例外はC/C++で、ここではあまり確立されたものがないから、良くも悪くも。複数の言語を混ぜる必要があるとき、こうした選択が後々すごく複雑なプロセスを生むかもしれない。パッケージシステムは物事を簡単にするけど、別の言語を使う必要があるときにはさらに複雑にしちゃうんだよね。

世界はまだ良いクロスプラットフォームのポリグロットビルドシステムを標準化していない。実際に存在するビルドシステムはBuckとBazelだけど、彼らは上司からの荷物が多すぎる。残念だね。

何か見落としてることあると思う?全ての言語に対して一つのビルドシステムが欲しい?そういうシステム(例えばBazel)もあるけど、マルチランゲージプロジェクトではよく使われてるよね。でも、実際には言語特有の知識を持ったビルドシステムの方がずっと扱いやすいってことが証明されてると思う。

Cはいろんな問題を解決して、パッケージマネージャー(もしくはそれに相当するもの)を追加すべきだったね。Zigがその隙間を埋めてる。

C++に標準化されたパッケージシステムがないのは実際いいことだと思う。これによって依存関係を導入する前に慎重に考えざるを得なくなるから、しばしばそういう依存関係にはセキュリティの脆弱性みたいな隠れたコストがあるんだ。多くの重要なシステムがC++で書かれてるから、各パッケージをしっかり監査せずに、簡単に手に入るサードパーティのパッケージに依存するのはリスクが大きすぎる。

Conanとvcpkgは、もう十分に確立されてるよね。

非常に理にかなった関心の分離だね。

Hacker Newsで議論の続きを見る