RustからZigへ！注目のリプレイス現場から進捗報告

Rustで書いていたプロジェクトをZigに書き換えるという挑戦の真っ最中です。現在の進捗や、実際に直面している壁について共有します。

Zigのインクリメンタルビルドは間違いなくキラー機能だよね。短期的には、それ目的で乗り換える理由もわかる。でも中期的には、Rustでも近いうちに実現することを期待してもいいんじゃない？速く動かしたいけど、速さを追い求めて足元をすくわれるような真似はしたくない。Rustの安全性、Zigの全機能、そしてガベージコレクションなしのGoのランタイムが全部手に入れば最高なんだけど……。今まさにそれを構築中だよ。

いい投稿だと思う。ただ一点だけ言わせてもらうと、rocやrustcみたいにマシンコードを出力するコンパイラにとって、メモリ非安全な処理が仕事の大部分だっていうのは、ちょっと書き方に語弊がある気がする。ホットなバイナリパッチやコードのリロード機能なら、確かにunsafeが必要になるよ。でも、普通の「実行ファイルを作る」ためのコンパイルなら、マシンコードを出力すること自体にunsafeは必要ないでしょ。unsafeが必要になるのは、言語のランタイム側の話だと思う。

「ReleaseSafeはUse-after-freeエラーを実行時チェックで捕捉し、解放済みメモリを使おうとしたらパニックする」とあるけど、Zigに詳しいわけじゃないから何か見落としてるのかもしれない。でも、ダブルフリーを含めてUse-after-freeを捕捉できるという証拠をこれまで見たことがないんだ。ブログ記事を書くにあたってドキュメントを読み漁って、Zigが挿入できる実行時のメモリ安全チェックについて調べたんだけど、「use-after-free」や「UaF」という単語はドキュメントのどこにも載っていなかったよ。「safety-checked」で検索しても関連するヒットはゼロだった。もしかしてリリースビルドでDebugAllocatorを使ってるってこと？それだとしてもUaFを確実に検知できるわけじゃないしね。

OCamlがプロトタイプのテスト環境として使えるほど柔軟で表現力豊かだったのに、実装言語には選ばれなかったっていうのは興味深いね。両者の成熟度を考えればなおさら。Zigのインクリメンタルビルドがduneより圧倒的に速いなんてことがあれば驚きだよ。クロスコンパイルは最高だけど、「なぜZigなのか」というセクションで言及されていないのが気になる。コンパイラを作る上でメモリ制御ってそんなに重要かな？Rust自体も元はOCamlで書かれていたし、WASMも同じ。メンテナたちが一斉に別の言語へ移行しようと決めるのは、どんなマイルストーンに達した時なのか気になるところ。

Rustで今後改善してほしいのはビルド周りかな。PCのストレージを無駄に食う一番の原因になってるし、大量のライブラリをビルドすると数十ギガ単位であっという間に溜まっていく。何がベストな解決策かはわからないけど、グローバルなビルドフォルダを設定して依存関係をプロジェクト間で再利用できるようにするのは一つの手。個人的には、どんな解決策であれ標準でそうなるべきだと思う。

重箱の隅をつつくようで悪いんだけど、パターンマッチの例にバグがある気がする。もし'verb'が"GET"で、'path'が"/users/1234/posts/1234/extra_path/and/more/"だったら、'post_id'はどうなるんだろう？"extra_path/and/more/"になっちゃうんじゃない？サンドボックスで試してみたら、案の定「Post ID: 1234/extra_path/and/more」っていう変な結果になった。原因は文字列リテラル内の文字の扱われ方にあると思う。このプログラム例は、文字列リテラルのパターンに含まれるスラッシュだけがマッチングに使われることを利用して、'page'にスラッシュを含められるようにしている。でも、入れ子の'match'で余計なスラッシュの可能性を考慮し忘れてるんだね。まだ記事を全部読んでないけど、パターンマッチでアロケーションが不要なのはすごく良さそう。文字列リテラルのパターンも興味深いけど、さっきのバグの件もあって確信は持てないかな。一部は非常に洗練されてるように見えるけど、具体的なセマンティクスについては何とも言えない。もしかしたら素晴らしくて、簡潔だからこそ他の言語よりバグが混入しにくいのかもしれないけど、今のところは判断がつかないよ。

この記事は、コンパイラ開発のための言語選定を科学的に行っていればもっと説得力があったはず。彼らは「高性能なコンパイラには低レイヤーのシステム言語が不可欠だ」という検証されていない仮説に基づいて、Rust以外で選べるのはZigしかなかったと結論づけているように見える。でも経験上、この前提は間違っている。コンパイラのパフォーマンスを支配しているのはアルゴリズムだよ。管理された言語（マネージド言語）の中でも最速のものは、どのアルゴリズムでもせいぜい2倍程度の差に収まる。一方、アルゴリズムによる性能差は無限大だ。Zig自体が、「低レイヤーのシステム言語で書けばコンパイラが速くなる」という説に対する完璧な反例になっている。Rocのコンパイル速度は毎秒約1.5万行程度らしいけど、これは速くない。1998年の時点でMLで書かれたコンパイラが毎秒3千行をこなしていたという事実もある。ZigでRocを書き直しているのは、著者にとって2回目のコンパイラ開発なんだろうね。コンパイラや言語の設計も他のスキルと同じで、今の自分から見ると、より高度な設計スキルを磨くことを犠牲にして、初期の設計に固執しすぎているように見える。今後Rocのために一番いいのは、今のコンパイラ作りをやめて、もっと小さなサブセットでセルフホスト可能なコンパイラを書くことだと思う。1万行以下のコードでできるはずだよ。今のZigベースのブートストラップコンパイラより速くなるかもしれない。もしうまくいかなくても、最低限使える小さなサブセットが特定できるし、30万行のコードをいじくるより、1万行のコードで様々な実装を試す方がずっといい。セルフホストすることで、Rocのどの機能が本当に重要かが見えてくるはずだし、実際にRocコードを書く時間も増えるはず。セルフホストに必要な機能は、どれも一般的に有用な機能ばかりだ。コンパイラを改善すれば、その先で作られるプログラムも改善されることになる。

本筋からはそれるけど、Rocの開発者がいたらRocのユースケースについて聞きたい。RocってC ABIに埋め込むようなスクリプト言語だよね？プラグイン用途でWASMと競合すると思ってる？（例えば巨大なRocプラットフォームとか）。アプリ作者がWASMレイヤーではなくRocレイヤーを公開するメリットは何？WASMならプラグイン開発者は好きな言語で書けるし。他にもアプリレベルの言語（例えばかなり小さなRocプラットフォーム）としても聞いたことがある。GleamのサーバーサイドHTTPコードや、Elmのクライアントサイドコードと競合すると思ってる？

コンパイル時間は過小評価されすぎだと思う。C++の一番嫌いなところは、ビルドに10分も待たされること。あれで集中力が完全に途切れるんだよね。

（笑）冗談で言ってるんだろうけど、完璧な世界にはC++を求めるってこと？