ハクソク

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

私たちのRustからZigへの書き換えの進捗状況

2026年7月16日原文(rtfeldman.com)

概要

  • Rocコンパイラは RustからZig への大規模な書き換えを実施
  • 機能パリティ を達成し、Rocci Birdなどのプロジェクトで成果を確認
  • 新コンパイラで ホットコードローディング や ゼロアロケーション なパターンマッチングを実現
  • 書き換え理由や Zig選択の背景、Rustとの比較を詳細に解説
  • メモリ安全性や開発体験など 両言語の利点・課題 を考察

RocコンパイラのRustからZigへの書き換えとその成果

  • Rocチームは 1年半かけて30万行のRustコードをZigに書き換え、機能パリティを達成
  • Bunプロジェクトの逆方向（Zig→Rust）書き換え事例と比較し、独自の経験を振り返り
  • Rocci Bird（WASM-4ゲーム）を新コンパイラでビルドし、 バイナリサイズを半分以下 に削減
  • 新コンパイラは 多くの新機能 を実装し、開発者やコントリビューターへの感謝を表明
  • 書き換え期間は 487日 で、Bunの11日間とは性質が異なる大規模な変更を伴う

新コンパイラの特徴と技術的進化

  • ホットコードローディング を開発時に自動で実現
    • サーバーや2Dゲームで、コード変更が即時反映されるデモを実施
    • デプロイ時はLLVM最適化済みの自己完結型バイナリを生成
    • クロスコンパイルも容易で、 同一バイナリ生成の再現性 を保証
  • パターンマッチング＋文字列補間 の新機能を導入
    • "/users/${id}"のようなパターンを 型安全かつゼロヒープアロケーション で実現
    • ランタイムのテンプレートパース不要で、高パフォーマンスと安全性を両立
    • 新しいroc-lang.orgのトップページでWebAssembly版コンパイラを体験可能

書き換えの背景と選択理由

  • Rocは 自動メモリ管理 を持つ非システム言語
    • 参照カウント方式でGCポーズ回避や最適化を実現
    • ポリモーフィック・デファンクショナライゼーション によるクロージャ最適化でヒープアロケーションを回避
  • 元実装のバグやアーキテクチャ的限界から 全面書き換えを決断
    • 多数のコントリビューターが部分的な再実装を検討していたため、 一括リライト を選択
    • コンパイラ界隈では スクラッチリライトが一般的 な手法

Zig選択の理由とRustとの比較

  • ビルド時間 の短縮を期待し、Zigを選択
  • メモリ制御 の柔軟さ（複数アロケータやStruct-of-Arrays標準対応）が決め手
  • 必要な低レベル機能の実装例が Zigエコシステムに多く存在
  • メモリ安全性支援 について、Rustのunsafe利用頻度が高くなる自作コンパイラ用途では、Zigの方が適合
  • Rustの borrow checker やエコシステムの一部は有用だが、 プロジェクトごとに最適な言語選択が異なる ことを強調

RustとZigのメモリ安全性・開発体験比較

  • Microsoftの調査 によると、セキュリティアップデートの約70%がメモリ安全性に起因
    • Rustはunsafeコードをisolatedにしやすいが、 コンパイラ開発ではunsafe多用が不可避
    • Zigはメモリ不安全なコードの 正当性検証支援機能が充実
  • Rocプロジェクトの経験では、 Zigの設計がコンパイラ開発に適していた と結論

このように、Rocチームの RustからZigへの全面的な書き換え は、単なる言語置換にとどまらず、アーキテクチャ刷新・新機能導入・開発体験改善を伴う大規模プロジェクトとなりました。 Zig選択の背景や、Rustとの実践的な比較 は、今後の言語選択やコンパイラ開発に関心のあるエンジニアにとって貴重な知見となります。

Hackerたちの意見

Zigのインクリメンタルビルドは、間違いなく素晴らしい機能だよね。短期的には、これを手に入れるために切り替える理由がわかる。でも、中期的には、Rustでも近い将来にこれが実現することを期待できないのかな？速く動きたいけど、自分の足を撃ち抜くような速さは求めてないんだ。もしRustの安全性とZigの機能、さらにGoのランタイムをGCなしで手に入れられたらいいのに…それに向けて頑張ってるよ。[=

└

素人の質問だけど、Goのランタイムの特別なところって、GC以外に何かあるの？

└

Rustのコンパイラが速くなるのを待つ代わりに、Zigに何かしらのバローチェッカーを追加するのはどう？それなら実現可能な気がするし、ユーザーランドでもできるかも。

└

もしRustの安全性とZigのすべての機能を手に入れられたらいいのに、定期的に使ってないコーデックストークンをこれに投げてるよ: https://github.com/ityonemo/clr

└

これに関しては進行中だよ: https://rust-lang.github.io/rust-project-goals/2026/roadmap-... このページの目標のほとんどは今年中に達成される予定だよ。

└

Rustのコンパイル時間は、Zigが安全になるよりずっと早くなるだろうね。

いい投稿だと思うけど、一つだけコメントを。> 「rocやrustcのようにマシンコードを出力するコンパイラにとって、メモリ安全でないことをするのは仕事の大部分だ」って書いてあるけど、これは本当にそうだとは思わない。ホットバイナリパッチやコードリロードの機能にはunsafeが必要だと思うけど、普通の「実行可能ファイルを生成する」コンパイルにはunsafeは必要ないよ。マシンコードを出力すること自体はunsafeを必要としない。言語のランタイムの方がunsafeを見つける可能性が高いと思う。

└

同意。これはかなり間違ってるよ。むしろ、コンパイラは木構造や整形されたプログラムの完璧なモデルだと思う。

└

あの文は私も混乱した。彼らのコンパイラのどの部分がメモリ安全でない操作を必要として、機械コードを生成するんだろう？

└

それは絶対に1000%間違ってるね。コンパイラは完全に抽象的なデータ構造で仕事ができるよ。もしメモリで危険なことをする必要があるとしたら、それはおそらくリンカーだと思う。

└

もし好意的に解釈するなら、出力された機械コードにバグがあると、それは実行されるときにメモリ安全でない誤コンパイルの可能性が高いってことだと思う。コンパイラ自体は「メモリ安全」であっても、生成されたバイナリは根本的に常にリスクがある（WebAssemblyを除いてはね）。コンパイラとバイナリの分離については十分理解してるし、信頼できないコードを安全にコンパイルできるのはいいことだけど、脆弱なバイナリを生成する完全に安全なコンパイラは、あまり良くないと思う。

└

ホットバイナリパッチやコードリロード機能には、確かにunsafeが必要になると思う。でも、普通の「実行可能ファイルを生成する」コンパイルには？ マシンコードを出力するのはunsafeが必要な部分じゃないよね。言語のランタイムの方がunsafeを見つける可能性が高い。そうそう！ マシンコードを出力するのはunsafeじゃない。バイトを書き込むだけだから。実際にそのマシンコードを実行する時に、潜在的なunsafeが出てくるんだ。俺が「仕事の大部分」と言った理由は、実際には多くのコンパイラがマシンコードを出力して実行するからなんだけど、コンパイラが両方をやる必要があるわけじゃないのはその通りだよ。君が挙げた例（ホットバイナリパッチ/コードリロード、言語ランタイムなど）に加えて、コンパイル時にユーザースペースのコードを評価すること（例えば、Rustのconst fnやRocのトップレベルに持ち上げられる可能性のある式）、テストを実行してその出力を確認してユーザーに表示する内容を決めることなどもあるよ。そういうことを考えて書いたんだ。

Hacker Newsで議論の続きを見る