まず結論から
Bunの内部実装をZigからRustに書き換える実験的ブランチが、Linux x64 glibc環境で 99.8%のテスト互換性 を達成したらしいです。いや、これがですね、めちゃくちゃすごい数字なんすよ。
そもそもBunって何してたの？
Bun は JavaScript/TypeScript のランタイム兼バンドラーで、もともと Zig という言語で書かれてました。Zigを選んだ理由は「C言語レベルの速度が出せて、メモリ管理を細かく制御できるから」ってやつです。
じゃあなんでRustに書き換えるのかっていうと、ざっくり整理するとこんな感じ：
- エコシステムの厚み ── Rustはcrateが豊富で、暗号系やネットワーク系のライブラリを自前で書かなくてよくなる
- メモリ安全性の保証 ── Zigは手動管理だけど、Rustは所有権システムで未定義動作をコンパイル時に弾ける
- コントリビューターの参入障壁 ── Zigより Rustのほうが書ける人が多い
99.8%の”残り0.2%”が気になる
互換性99.8%ってほぼ完璧に見えるけど、たぶん原因はこのあたりじゃないかなと予想してます：
- 浮動小数点の微妙な丸め差異（言語ごとにデフォルトの丸めモードが違うことがある）
- FFI境界でのメモリレイアウトのズレ（構造体のパディングとか）
- 非同期I/Oのタイミング依存テスト（io_uringまわりとか怪しい）
ここは推測なんで、公式が詳細出したらまた追記したいです。
パフォーマンスと互換性のトレードオフ
いや、これがですね、ものづくりしてるとめっちゃ共感するんすよ。Arduinoでセンサー読む処理を速くしようとしたら精度が落ちる、みたいな。速さと正しさは常にトレードオフなんですよね。
Rustに書き換えることで unsafe ブロックが減ってバグは減る。けど、Zigで書いてた低レベル最適化の一部は抽象化の壁に当たる可能性もある。99.8%まで持ってきた時点で、そのバランスの取り方がうまいんだなと思います。
まとめ
- Bun の Rust rewrite が Linux x64 glibc で 99.8% テスト互換
- 書き換えの動機はエコシステム・安全性・コミュニティの3点
- 残り0.2%の原因は浮動小数点やFFI境界あたりが怪しい（個人的推測）
- 速さと正しさのトレードオフは、規模が違っても本質は同じ
「わからんこと」がまた増えたので、正直ワクワクしてます。続報出たらまた書きます。
コメント