- x86_64 ターゲットでは、Zig のセルフホスト x86 バックエンドがデバッグモードでデフォルトとして適用されるようになった
- 従来の LLVM ベースよりも多くの動作テストを通過し、より高速なコンパイル速度を達成した
- セルフホスト バックエンドの導入により、Zig のコンパイル時間が大幅に短縮され、一部作業の効率も向上した
- 最近では、改良されたビルドシステム、BSD 系 OS のサポート拡大、UBSan ランタイムの改善など、複数の機能強化が進んでいる
- 標準ライブラリと独自ツールの最適化により、Zig ならではの競争力が強調されている
最新の主要ニュース要約
2025年6月8日 – セルフホスト x86 バックエンド、デバッグモードでデフォルトに移行
- x86_64 ターゲットでは、今後はデフォルトで Zig のセルフホスト x86 バックエンドが使用される
- 以前は LLVM を使ってビットコードからオブジェクトファイルへ変換していた
- Windows では COFF リンカ関連の作業がさらに必要なため、変更は見送られている
- Zig の x86 バックエンドは1,987件の動作テストを通過し、LLVM バックエンド（1,980件）よりも高い安定性を示している
- 全体のテスト数は 2,084 件だが、一部は LLVM 自体のテストと重複しているため、セルフホスト バックエンドのテスト時にのみ追加確認している
- Zig が独自コードジェネレータの開発に注力する主な理由は、ビルド速度で LLVM を大きく上回るためである
- ベンチマークでは、
zig build-exe hello.zig -fllvm（LLVM 使用）の平均ビルド時間は 918ms、セルフホスト バックエンドは 275ms を記録した
- メモリ使用量、CPU サイクル、命令数、キャッシュミスなど、あらゆる面で大幅に改善された性能を確認できる
- Zig コンパイラ自体のような大規模プロジェクトのビルド時間も 75 秒から 20 秒へ短縮された
- 今後はコード生成の完全並列化の実装、リンク機能の強化、aarch64 バックエンドの開発などが予定されている
- 新しい Legalize パスの導入により、aarch64 の作業も加速する見込みである
- 最新の変更は Zig のmaster ブランチ最新ビルドで直接試すことができる
2025年6月6日 – ビルドシステム紹介動画
- Zig ビルドシステムの入門者向け YouTube ガイド動画が公開された
- Zig モジュールやパッケージの作成、それらを他のプロジェクトからインポートする方法などを説明している
- ビルドシステム関連の追加動画も、今後シリーズとして継続的に公開される予定である
2025年5月20日 – FreeBSD および NetBSD ターゲットのサポートを強化
- Pull Request #23835、#23913 のマージにより、
zig cc と zig build でFreeBSD 14.0.0+ および NetBSD 10.1+ ターゲットのバイナリをビルドできるようになった
- これまで glibc で用いられていたlibc および関連ライブラリ情報の抽出戦略を BSD 系にも拡張適用した
- 生成された
abilists ファイルは Zig とともに配布され、クロスコンパイル時に各libc ライブラリに正確に対応するスタブライブラリを生成できる
- システムおよび libc ヘッダも最新 OS バージョン基準であわせて提供される
- OpenBSD、Dragonfly BSD、SerenityOS、Android、Fuchsia などもサポート対象としている
2025年4月9日 – 公式 Zig サイト、スタンドアロンの Zine としてビルド
- 公式 Zig ウェブサイトは、現在 スタンドアロンの Zine としてビルドされる構成へ変更された
- 従来のビルドスクリプトから単一実行ファイルへと発展した
- 実際に試してみるには良いタイミングだと案内されている
リリースと機能改善のニュース
- 0.14.0 リリースがまもなく公開予定であり、注目すべき改善の多くはすでに適用されている
- C interop と UBSan（Undefined Behavior Sanitizer）ランタイムの改善により、以前は曖昧だった SIGILL エラーが、より具体的で有用なエラーメッセージに置き換えられた
- 例）符号付き整数オーバーフローの発生箇所と原因を明確に表示し、デバッグ効率を大きく高めている
- 残る UBSan の制約:
- C++ vptr に関する動的型およびライフサイクル検査は未対応
assume_aligned、__nonnull などの属性について、正確な位置表示は未完成
2025年2月7日 – デバッグアロケータと SmpAllocator の革新
- デバッグアロケータが再設計され、ランタイムのページサイズ認識をサポートし、さまざまな最適化が反映された
- メモリマップ生成の削減、不要な 0xaa/0x00 memset の繰り返し除去、探索および trie データ構造の削除など
- ページ内にメタデータをインラインで保存し、コンパイルエラーや検証を容易に実装できる
- 従来の C ベース malloc と比べて可読性と保守性で優位性を確保した
- 並行環境に最適化された SmpAllocator の開発により、マルチスレッド環境でのメモリ割り当て実行効率が大幅に高まった
- glibc との性能比較ベンチマークで、速度とリソース利用効率が実証されている
- 結果として、Zig の使い勝手が C や libc を上回る重要な転換点として評価されている
2025年1月24日 – Zig 専用のデバッグ環境を提供
- Jacob が Zig 向け LLDB（デバッガ）フォークを開発し、セルフホスト バックエンドのデバッグサポートを強化した
- LLDB フォークのビルド方法と使い方は Wiki 文書で提供されている
- Zig のセルフホスト バックエンドを使う開発者は、このツールによってさらに高度なデバッグ環境を活用できる
結論
- Zig は、独自基盤による性能向上、ビルド効率、デバッグのしやすさの強化を中核目標として、革新的な変化を継続して推進している
- 独立したアルゴリズム、コンパイラ、ビルド／ランタイムツールのすべてにおいて、差別化された競争力を確立しつつある
- BSD など多様なプラットフォームのサポート、ユーザー本位のメッセージ改善、メモリモデルの革新を含め、ソフトウェアエンジニアの実務にとって実質的に有益な進展を続けている
1件のコメント
Hacker Newsの意見
私の知る限り、Zigは開発体験をより良くするために日々さまざまな機能に取り組んでいる。たとえば最近ではこのPRもあった。以前からZigではホットコードスワッピング（hot code swapping）も開発計画に入っていたし、この開発速度ならおそらく1年以内にx86_64でこの機能が使えるようになるのではと思う。個人的に一番大きな不満は
comptimeの速度だ。コンパイル時にbrainF** DSLを動かした実験があったが、本当に遅かった（でも面白い実験だった）。コンパイラのこの部分がいつごろ改善されるのか気になる。新しいバックエンド群にもとても期待していて、Zig向けに自分のURCLバックエンドも作ってみたい気持ちがある 😉comptimeの性能改善については何をすべきかすでに分かっていて、かなり前に関連ブランチも始めたことがある。ただ、これは意味のある規模でセマンティック解析コードを作り直す必要がある部分なので、重要な仕事の一つではあるものの、他の優先事項と競合している
ホットコードスワッピングはゲーム開発の分野でとてつもない変化をもたらし得る機能だ。Zigではこれが基本的にコンパイラフラグだけでサポートされる予定だという点に驚かされる。clangでは試すことすら難しいからだ
URCLについて深く見たわけではないが、これがまた別の rabbit hole に私を引きずり込んでいる。Minecraft向けに作られたIRが、言語の実際のコンパイルターゲットになるという本当に奇妙なシナリオまで想像してしまう
カスタムバックエンドを作るのが簡単なのか気になる。まだ自分では試していないが、AIRを受け取ってメモリ安全性レポートを生成するバックエンド実験をしてみたいと思っている（たとえば、未定義値の使用、スタックポインタのエスケープ、use-after-free、double free、alias xor mut などをチェックする形）
comptimeが本当にそんなに遅いのか気になる。私はJSON-RPCライブラリを作っていて、コンパイル時にcomptimeを積極的に使ってJSONを任意の関数へディスパッチしている。Zigの強力な静的型付けのため、ランタイムで任意パラメータを持つ関数へ動的にディスパッチすることができず、コンパイル時に関数型のマッピングを生成するやり方を使うしかなかった。そうすると各関数ごとにcomptimeされたコードが複製され、バイナリサイズが大きくなるのではないかと心配している
すでにここまで到達しただけでもすごい成果だ。devlogでも明かされていたように、これからがさらに楽しみだ。コンパイラがビルド時にバイナリの必要な部分だけを書き換えるという発想は新鮮で大胆に感じられ、Zigプロジェクトのおかげで今や実現可能な目標になった。今後はとても面白い時期になりそうだ
Zigのパッケージ管理はRustに比べるとやや手動寄りだ。CLIでパッケージURLを直接取得し、ビルドスクリプトでモジュールをインポートする方式になっている。この方式の利点は、任意のアーカイブも簡単に依存パッケージとして使えることで、多くのZig向けCライブラリパッケージは単に未加工の tarball リリースをビルドスクリプトから直接つなぐ構造になっている。ただし、初心者には少し複雑かもしれない
SDL3については、ネイティブなZigラッパー（https://github.com/Gota7/zig-sdl3）と、より単純にCライブラリ/APIをZig向けにしたhttps://github.com/castholm/SDLの2つがある
QuickJSはC API（https://github.com/allyourcodebase/quickjs-ng）のみをサポートしている
ZigはCパッケージを直接使うのが非常に簡単だが、型が厳密なのでAPIを扱う際に型キャストが頻繁に必要になることがある
dmd Dコンパイラは、自身をデバッグビルド基準で約18.4秒でコンパイルできる。
私のプロセッサはかなり古いAMD Athlon 64 X2（4400+）だが、あまりに速く動くのでまだアップグレードすらしていない
（詳細なCPU情報一覧を含む）
fast development cycle のためにZigを20秒でビルドするガイドがあるのか気になる。以前Zigをビルドしたときは複数ステージ（特にWASMでのブートストラップ）があって本当に時間がかかった記憶がある
ZigがLLVMを使った状態でも自身を75秒でコンパイルするというのはものすごく驚きだ
Zigに無理な要求をするつもりはまったくなく、オープンソースであることもよく理解しているが、現実的な1.0のリリース時期に最も関心がある。
Zigは低水準言語に私が求めていたものをほぼ完璧に備えた言語で、あとは安定化を待っているところだ。
そしてZigのミニマリズムな設計哲学には心から感心している
まったくの初心者として、Zigが他の言語と比べてどんな利点を持つのか気になる。よりモダンなCとして理解しているが、何が「モダン」なのかが知りたい
defer、errdeferブロックで、関数の戻り時やエラー発生時の自動クリーンアップ処理を実装できる私はCにあまり親しみがなく、Cのいろいろな不合理さや直感に反する点のせいで低水準プログラミングにはいつも参入障壁を感じていたが、Zigは初めてシステムプログラミングを楽しく面白いと感じさせてくれた言語だ
Zigを20秒でビルドできるガイドがあるのか気になる。開発サイクルを速く回したいのだが、stage1/2/3のどれもビルドに時間がかかり、貢献しづらかった経験がある
Zigで
zig initのHello Worldをビルドすると9.3MBになるが、-Doptimize=ReleaseSmallフラグを使うと7.6KBまで減るフラグ1つで1000倍以上の差が出る状況だ
-OReleaseSmall -fno-strip では580KB、-ODebug -fstrip では1.4MBにまでなる
Zigのx86バックエンドではZig専用のLLDB forkによってはるかに優れたデバッグ体験が提供される
現在comptimeロジックをデバッグ中にステップ実行で見られるかどうかはよく覚えていないが、最近の議論の話題にはなっていた
Juliaは性能面の利点を得るために、コンパイラとしてZigを検討してもよいのではないかと思う。リリースのたびに性能低下を心配して落ち着かないJulia開発者たちの気持ちも覚えている
Juliaは事実上LLVMに強く結びついている。エコシステムのさまざまな部分がLLVM intrinsics、autodiff（Enzyme）、GPUコンパイルなどの存在に依存している。
コンパイラはかなりリターゲット可能になりつつあり、この点も現在活発に研究されている。
将来的には、Zigが言語の一部に対する代替コンパイラになる姿も想像できる
LLVM自体がJuliaのpublic APIだという意見もある。実際、@code_llvmのように直接IRを表示するマクロもある
コンパイル時間短縮には確かに効果があるだろうが、Julia側でもまだやるべきことは多い
コンパイルキャッシュのさらなる細分化や、invalidation防止のためのツール整備、world splitting 最適化の除去、コンパイラのマルチスレッド活用の拡大、特定シグネチャに対する自動事前コンパイル、lazy にコードをコンパイル／ホットスワップする機能などがある
これはZigにとって大きな前進であり、Rustと比べたとき今後の主な差別化要素になる方向だと思う。ちなみに、パフォーマンス分析ツールのレンダリングコードの大部分は私が自分で書いたもので、自分のコードがオンラインで広く使われているのは嬉しい
poopプロジェクトのリンク
rustc_codegen_craneliftを参照
これこそが、Zigにasync/await機能を再導入するための前提条件の一つだと思う
asyncに関するZigの公式FAQも参考になる
この部分はすでに整理済みで、今後2〜3か月以内に興味深いアップデートを公開できるはずだ。ほとんど標準ライブラリを作り直すかのように、I/O全体を再設計している
リンクによれば、asyncはそもそも戻ってこないか、少なくとも2028年までは夢のまた夢のように見える