ハクソク

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

Zig ELFリンカーの改善開発ログ

16時間前原文(ziglang.org)

概要

  • Zigのmainブランチの2026年の主な変更点を解説
  • 新しいELFリンカやビルドシステムの大幅な改良
  • LLVMバックエンドでのインクリメンタルコンパイル対応
  • 型解決ロジックの抜本的な見直し
  • 各機能の実用的なメリットや移行時の注意点も記載

2026年 Zig mainブランチの主な変更点

  • ELFリンカの改良

    • 新ELFリンカがZig 0.16.0で初登場
    • 当初はZig単体コードのみ対応、外部ライブラリ非対応
    • -fnew-linkerオプションで有効化可能
    • 最新のPRでLLVM・LLDライブラリ連携が可能に
    • Zigコンパイラ自身のビルドにも対応

  • 高速インクリメンタルビルドの実現

    • 新リンカの目玉機能は高速なインクリメンタルコンパイル
    • x86_64 Linux環境で外部ライブラリやCソースを含めても遅延なし
    • 例：Tetrisクローンのビルドが1回約30ms
    • Zigコンパイラ自身の再ビルドもミリ秒単位に短縮

  • 現時点の制約と今後の予定

    • DWARFデバッグ情報生成は未対応（今後の最優先課題）
    • x86_64 Linuxのmasterブランチ利用者は新リンカ＋インクリメンタルビルドを推奨
    • 不具合報告も歓迎
    • 0.17.0リリースも間近

ビルドシステムの大幅な刷新

  • ビルドシステムの分離構造

    • これまでbuild.zigとビルドシステム実装が1つの巨大プロセスで動作
    • 新方式では「configurer」と「maker」に分離
      • configurer：build.zigをコンパイルし、ビルドグラフをバイナリ設定ファイルにシリアライズ
      • maker：Releaseモードでコンパイル、設定ファイルを受け取りビルドグラフを実行
    • makerはZigバージョンごとに1回だけコンパイル（グローバルキャッシュ利用）

  • 主なメリット

    • ビルド速度の大幅向上
    • build.zigのロジックのみ変更時に再コンパイル
    • 設定ファイルのキャッシュ利用で無駄な再実行を回避
    • ビルドグラフ実行プロセスは最適化済みで動作

  • ベンチマーク比較

    • 従来：zig build -h 実行に約150ms
    • 新方式：約14ms（90%以上短縮）
    • メモリ・CPU・キャッシュ効率も大幅改善

  • API互換性と移行時の注意点

    • ほぼ非破壊的だが、一部ビルドスクリプトAPIが変更
    • 例：run_cmd.addArgs(args) → run_cmd.addPassthruArgs()に変更
    • 引数変更時のビルドスクリプト再ビルドが不要に

  • 開発版の利用推奨

    • 0.17.0リリース前に新機能のテストやフィードバック募集
    • もし0.17.0でビルドが壊れても0.17.1で修正可能

LLVMバックエンドでのインクリメンタルコンパイル

  • LLVMバックエンドの改善点

    • LLVMコード生成バックエンドでインクリメンタルコンパイル対応
    • LLVM Emit Object自体の高速化は不可
    • Zigコンパイラ内の処理時間を最小化
    • コンパイルエラー時はエラー表示が即時化
    • 成功時もわずかにビルド時間短縮

  • 利用方法と安定性

    • masterブランチで利用可能、0.16.0にも搭載予定
    • -fincremental --watchオプションで有効化
    • コアチームは1年以上実運用し、ユーザーからも好評
    • バグ報告も歓迎

型解決ロジックの抜本的見直し

  • 主な変更点

    • Zigコンパイラ内部の型解決（type resolution）ロジックを大幅刷新
    • 型のフィールド解析を遅延実行
      • 実際に初期化されない型は詳細解析をスキップ
      • std.Io.Writerのような名前空間兼用型に有効
    • 例： 
      const Foo = struct { bad_field: @compileError("i am an evil field, muahaha"), const something = 123; };
comptime { _ = Foo.something; }
      • 以前はコンパイルエラー、現在は正常コンパイル

  • 依存ループ時のエラー改善

    • 依存ループ発生時のエラーメッセージが詳細化
    • どの型・フィールドがループしているか明確に表示
    • 問題箇所の特定が容易に

  • 今後の展望

    • 型解決ロジックの整理により、今後の言語仕様拡張や最適化が容易に
    • ユーザー体験の向上

このように、2026年のZig mainブランチは、ビルド速度・開発体験・内部設計の全方位で大きな進化を遂げています。今後のリリースにも注目。

Hackerたちの意見

これが、数年前にZigのことを初めて聞いたときに衝撃を受けた約束なんだ。これが現実になって本当に嬉しい！

今進められているこの作業が、Bunのドラマに対する反応なのか気になるな。

└

まったく関係ないよ。これに関してはずっと前から取り組んでたし、開発ログをさかのぼればその話題についてのエントリーがたくさん見つかるよ。逆に、今は「ドラマ」があるからこそ、みんなこの作業についてのコミュニケーションに対してオープンになってるんだ。この投稿はアンドリューと共同執筆したもので、2020年のものだよ。そこで、デバッグビルドパイプラインからLLVMを取り除くアイデアを発表して、それ以来着実に進んでるんだ。ただ、全ての主要ターゲットのためにフルコンパイラーパイプラインを立ち上げるのは簡単じゃないけど、ようやくそこに近づいてきたよ。https://kristoff.it/blog/zig-new-relationship-llvm/

└

ほんとに、無駄なドラマをかき立てないと動けない人もいるよね。それが本当かどうか、気になるところだな。

└

ないよ。これらのことはしばらく前から進行中だったし、Zigの反AIの姿勢を考えると、買収以来Bunは見限られたんじゃないかな。

└

「Bunドラマ」なんて全然ないよ。ただ目標や方法論が違う2つのプロジェクトがあって、相互に相容れないだけ。結局、退屈な人たちがちょっと騒いでるだけだよね… とにかく、このマイルストーンにはめっちゃ嬉しいし、感動してる！

ZigやRustみたいなのは、Cが使えるニッチな場所でしか通用しないと思ってたけど、もうそうじゃないね。リンクや他のターゲットでのインクリメンタルコンパイルが実現すれば、ZigはCの代替になるし、CやRustのパフォーマンスでJSやPythonの速度でイテレーションできるようになるんだ。アンドリューの初期の夢、妥協のないUXを持つDAWを作ることも、ずっと作りやすくなるはずだよ。誰かがZigネイティブのイミディエイトモードやリアクティブUIフレームワークを作ればだけどね。とはいえ、@cImportの削除にはちょっとモヤモヤしてるけど！これがないと、「Cのコトリン」とは自信を持って言えなくなっちゃうな。

└

Zigネイティブのイミディエイトモードdvui？

└

もうある程度は可能だよ。ここに僕のZig DAWがあるよ。音声エンジンには素晴らしいけど、UIは今のところimguiを使ってる。

└

Kotlin of C それは紙の上では良さそうだね。でも、Kotlinだけを学ぼうとした僕から言わせてもらうと、Javaのライブラリを使うためにJavaを学ばなきゃいけないのが面倒なんだよね… あれはシームレスに連携するからさ。結局、新しい学習者には逆に難しくなるかもしれない。ここでZigやCの話はしてないけど、Kotlinの経験からちょっと愚痴ってるだけ。

└

わからないけど、@cImportを単に"@import"にするのは改善だと思う。

└

それによって、JSやPythonの速度で、CやRustのパフォーマンスが得られる。Goはもうそれを実現してるんじゃない？ > ZigやRustみたいなのは、Cが使えるニッチなところでしか通用しないと思ってたけど、もうそうじゃないね。このリンカーと他のターゲットでのインクリメンタルコンパイルが実現すれば、ZigはCの代替になるよ。そうだけど、Zigの哲学自体がCに似てるから、結局Cが使えるニッチでしか役に立たないと思う。ZigでJSやPythonの速度で開発するのは無理だし、メモリのライフサイクルやオブジェクトのライフサイクルにいつも悩まされるからね… Rustはかなり違うよ。

└

ZigやRustみたいなのは、Cが使えるニッチなところでしか通用しない。ほぼ正しいね。 > ZigはCの代替になるし、それによってJSやPythonの速度で、CやRustのパフォーマンスが得られる。根本的に無理だよ。C/Zig/Rustは100%のパフォーマンスを目指してるけど、それは他の何かとトレードオフしなきゃいけなくて、結局プログラマーの労力や時間が関わってくる。家を100%速く、100%安く、100%の品質で建てることはできないよ。せいぜい、減少するリターンの法則を巧妙に利用して、3つの領域で約80%を目指すのが現実的。これがGoがやろうとしてることだよ。 > このリンカーと他のターゲットでのインクリメンタルコンパイルが実現すれば、 そもそも、より良いリンカーと速いコンパイル時間がこの目標を達成するのはなぜ？ Zigは低レベルな言語だけど、メモリ安全性が低くて、各アロケーションについて選択を迫られるから、アプリケーション言語としては魅力が薄いよ。ZigとPythonは全然違う世界だね。

これらの改善はかなり期待できるし、リリースされたら試してみるのが楽しみだよ。0.17.xのWindows版にもコンパイラの改善があるのかな、それともこれはLinux専用？

└

0.17には間に合わないかもしれないけど、COFFリンカーに取り組んでる人がいるみたいだよ。 https://codeberg.org/kcbanner/zig/src/branch/coff_linker_wip

そうなんだ、このリンカーは高速インクリメンタルリンクを行うから、開発のイテレーション速度が上がるのはいいね。でも、インクリメンタルリンクはリンクタイム最適化とは相反するんじゃないかな？つまり、リリースビルドではこのオプションを使いたくないってことだよね？

└

「cl:define-compiler-macro」を調べてみて。過去にやったことがあるよ。それに、LTOはCとC++の人たちが合意し始めた時期だね。

同じようなコンパイル性能を持つ他の言語ってある？俺が知ってるのはTurbo Pascalだけなんだけど。

└

cgoを無効にした状態のGoって、まだ少なくとも同じくらい速くコンパイルできるんじゃない？

└

コンパイル速度は言語によるものじゃないと思う。最適化のやり方や機械コードの生成にもっと関係してるし、コンパイラやビルドシステムの実装の速さも影響するよね。

└

Delphi、D、Nim、Go、C# / .NET Native / Native AOT、Oberon（言語ファミリーの中のどれか）、Ada（コンパイラによるけど、7つのベンダーがある）、…

└

みんなDを忘れがちだよね。たぶん、Goよりもコンパイルが速いと思う。

Rakuのバックエンド（Meta-Object Aware Runtime Virtual Machine - MOARVM）をCからZigに移植するっていう噂があるみたい。例えば、Zigのハッシュオプションの幅広さが大きな最適化になるかも。聞かれたから言うけど、フロントエンドはNQPで自己ホスティングしてて、Raku GrammarsのRakuASTプロジェクトも進化してるよ。新しいAST（6.e.PREVIEW）は、もっと良いイントロスペクションと高レベルの最適化ハンドルをもたらす予定。だから、VMをリファクタリング/書き直して大幅な速度向上を図る可能性は十分にあるよ。興味がある人やスキルがある人は、ぜひ -Ofun に参加してね！ https://raku.org/community

└

ちょっと訂正、moarは「ランタイム上のメタモデル」の略で、「メタオブジェクト対応ランタイム」じゃないよ。

└

RakuとZigを遠くから見守ってるんだけど、両方の言語は「楽しむために最適化されている」って共通点があるから、一緒になるのも不思議じゃないね。Zigはコンパイル速度に焦点を当ててて、開発者にもっとコントロールを与えてる（Cよりもね）。RakuはPerlの子孫で、巨大なおもちゃ箱みたいで、使うなって言う人はいない。両方とも開発者に自由を与えてくれるから、本当に楽しい。成熟度はあまり高くなくて、市場シェアも限られてるけど、それを気にしてないコミュニティがあって、雰囲気もいい。Rustとは真逆だね。Rustの言語は「束縛と規律」の哲学を持ってて、ADAみたいに、間違いを犯さないようにするためにできることは何でもするって感じ。そこには価値があるけど、特に楽しいわけじゃない。コミュニティもルールで定義されてて、行動規範は悪名高いし、目的はあっても、ルールを前面に出すとコミュニティが楽しい場所に見えないんだよね。それに、Rustコミュニティは攻撃的で「Rustで書き直せ！」とか「メモリ安全じゃない言語はダメ！」とか言ってるのを見たことがない。Zigコミュニティからはそんな態度は感じたことがないよ。彼らは自分たちの言語が世界一だって言うけど、使わないことを責めることはない。Rakuに関しては、他の誰も使わないことを気にしてないみたいで、前に進み続ければいつか使われるようになることを願ってるみたい。

└

もしこれを試すことにしたら、進捗や苦労をIRC、ziggit、またはZSF zulipでシェアしてね。助けてくれる人がたくさんいると思うよ。頑張って、楽しいハッキングを！

俺はハッカーニュースの開発者みたいにクールじゃないけど、Zigをよく見るようになった。これって今のトレンドなの？もうRustは終わり？

└

Zigはもう約10年も前からあるよ。Rustよりも低レベルで軽量だし、目指すものが違うからトレードオフも異なる。Rustが新しいC++なら、Zigは新しいCだね。

メモリセーフな言語を作ってるんだけど、Zigにトランスパイルして、Goみたいなランタイムで動くんだ。解釈実行（GCなし）かコンパイル済みで動かせるよ。高レベルでRubyみたいな感じだけど、TypeScriptみたいにインクリメンタルな型付けがある。Zigチームは0.16から今までの間に、RustじゃなくてZigをターゲットに選んで正解だったなって思わせてくれた。Rustの方がターゲットにしやすかったかもしれないけど（だって、もうメモリセーフだし）。Zigのビルドシステムデザインが一番だと思ってたし、トランスパイレーションのターゲットとしても最高だと思ってる。6ヶ月経った今でもそう思う。GCなしにした主な理由は、エイリアシングがすべての悪の根源だと思ってるからで、グローバルな複雑さがゼロの言語が欲しいんだ（でも、使うのに博士号はいらないやつ）。

└

似たようなものに取り組んでるよ。GCなし、Pythonっぽい感じ、管理されたメモリ、Cに近いパフォーマンス。ここにあるよ： https://blorp-lang.org もしアプローチを比較したいなら。

1.0が出たらいいな。それがあれば、ビジネスにも採用されると思う。