なぜZigに惹かれたのか——明示的なメモリ管理という思想
筆者がZigに出会ったのは2020年、プログラミングメンターの紹介がきっかけでした。当時のZigはまだ新しく不安定な言語でしたが、コンパイル時のコード実行やシンプルな抽象化に魅力を感じたといいます。(出典)
特に影響を受けたのが、Zig開発者Andrew Kelley氏の講演「Software Should Be Perfect」でした。ここで語られた、失敗し得ることを前提にした明示的なメモリ確保、隠れた制御フローの排除、普遍的な再利用性という価値観は、筆者がプログラミング言語に求める基準そのものになったとのことです。
「失敗し得る明示的なメモリ確保」という思想が、その後の言語選びの物差しになった。
なぜRustに乗り換えたのか——安定志向の裏にあった現実的な理由
筆者がZigを離れた理由は、次のような現実的な悩みでした。
- 言語自体の破壊的変更が頻繁で、複数バージョンを扱いやすくする「anyzig」のようなツールもまだなかった
- エコシステムが未成熟で、参考にできるライブラリや実例が少なかった
- 標準ライブラリやドキュメントが不安定で、理解した仕組みがすぐに変わってしまった
対照的にRustは、学習コストこそ高かったものの、一度習得すれば安定して動く言語だったと筆者は述べています。(出典)
Rustを学ぶのは苦痛だったが、一度理解すれば、ちゃんと動いた。
なぜまたZigに戻ったのか——Rustで募った不満とガバナンスへの懸念
筆者がRustに感じるようになった不満は、FFI(外部言語との連携)の難しさ、クロスコンパイルの煩雑さ、隠れた(失敗しない前提の)メモリ確保、LLVM依存によるプラットフォーム対応の遅さなど多岐にわたります。加えて、Rust Foundationに複数の大企業が多額の資金を提供している構造が、言語の意思決定に影響しているのではという懸念も語られています。
| 観点 | Zig | Rust |
|---|---|---|
| メモリ確保の扱い | 明示的で失敗し得る設計を志向 | 一部で隠れた(infallibleな)確保が残る |
| エコシステム成熟度(当時) | 未成熟でライブラリが少なかった | 長年の実績で強いエコシステムがある |
| ガバナンス | — | 大企業からの多額の資金提供が意思決定に影響しているのではとの懸念 |
筆者は最後の決め手として、AIによるコード生成(いわゆるバイブコーディング)の広がりも挙げていますが、具体的にどう影響したかは元記事の続きで語られています。
普段Claude Codeを使ったバイブコーディングを実践している身としては、この指摘は少し気になるところです。生成AIでコードを書く機会が増えるほど、コンパイラや型システムが人間の見落としをどれだけ拾ってくれるかという安全性の価値は、むしろ高まっていくのではないかと感じます。