BunのバックエンドをRustで再実装：次世代ランタイムの舞台裏

JavaScriptランタイム「Bun」のコア部分をRustで再構築するプロジェクトに関する議論です。パフォーマンスの限界に挑む試みや、なぜRustが選ばれるのか、その技術的背景についての動向をまとめています。

興味深いと思ったのは、この話題に関する議論のほとんどが、書き換えがOpusのようなモデルではなく、Fableで行われたという前提で進められていたことだ。少なくとも部分的には、そうした思い込みが「書き換えは実現不可能だ」あるいは「良いアイデアではない」という議論の根拠に使われていた。明らかにモデルそのものが物語を根本から変えるわけではないけれど、少なくとも自戒として、Anthropicやその関連組織が内部で使っているモデルの能力を決めつけることには、もっと慎重でありたい。

Bunそのものや書き換えの性質についてコメントするつもりはないけど、Zigから単純に書き換えただけでメモリリークが解消され、安定性が向上し、バイナリサイズが20%縮小し、パフォーマンスが5%向上したという事実は、Zigにとって決して良いことじゃないよね。

Claude Code v2.1.181（6月17日リリース）以降は、Rust版のBunが使用されています。

Bunの死という噂は、かなり大げさだったようだな。

それが強力なテストスイートの力だよ。LLMは検証可能な報酬がある時に真価を発揮する。今後、Rustで書き直されるプロジェクトはもっと増えるだろうね。Rustは型システムによる検証が強力で、オーバーヘッドが少なくGCもないから、こうした書き換えには理想的だ。エージェントによるコーディングが主流の時代において、GC付き言語を使う理由はどんどん減っている。RustはLLMによるコーディングにとってローカルな最適解だと思う。将来的にはもっと優れた言語が出てくるかもしれないけど、当面はRustが支配的だろうね。

Rustへの書き換え、ICUの変更、そしてコードの折りたたみの統一を合わせると、BunのバイナリサイズはLinuxとWindowsで約20%縮小しました。

これに驚いている人は、実際のZigコードがどんなものか見たことがないんだろうな。Zigの明示性と抽象化の欠如には、これまで見た中で最も冗長なプログラミング言語のひとつと言えるほどのコストがある。Goよりも冗長だよ。パターンマッチングやジェネリクスのようなモダンな言語の基本機能がなく、何でも手動で後片付けしなきゃいけない。つまり、一度でも忘れたらメモリリークってこと。間違いを防ぐという意味では、多少の抽象化は実際メリットがあるんだよ。皮肉なことに、ZigはLLMなら冗長さを厭わずに書けるから、LLMに書かせるのが一番なのかもしれない。

大きなプロジェクトを書き直すたびに、主要なバグやほとんどの小さなバグを修正しながら、より小さく、より高速にしてきたよ。今のチームでも同じような経験がある。同じ規模でZigからZigへの書き換えを行ったら、品質にどう影響したのか見てみたいものだ。

コードの変更がバグを生む理由や、うまくいかない理由を徹底的に突き止める

今の僕の最大の悩みは、コードのシンプルさについてレビューを得ることができないことだ。/simplifyコマンドじゃ役不足なんだよね。特定のバグを取り除いたり、全体として動作するようにしたりする分にはうまくいく。特に、Bunの書き換え事例のように参考コードがある場合や、進め方の「仕様」がしっかり決まっている場合はなおさらだ。

この記事ではコストについては触れられていないね。仮にmythosが関わっていたとして推測すると、128個のx20最大アカウントが必要だとしたら25,600ドル、あるいはAPIコストだけで75,000ドル以上かかっていることになる。75,000ドルあれば、言語Aから言語Bへの移植で使われる意味論的な変換やその他のテクニックを駆使して、10日ではなく1ヶ月かけても、もっと良い結果を出すエンジニアチームを雇えるよ。APIコストが1万ドル以下でこれが実現できるようになったら、もっとワクワクするんだけどな。

ずっと感じてたんだけど0、Bunを作った人たちは第一の目標として「Zigを使いたい」という欲求があったんじゃないかな。それはそれで素晴らしいし、僕もZigは好きだし、自分たちのやり方で何かを作るのは良いことだと思う。

ただ、Bunを使うことには懐疑的だったんだ。というのも、僕は「プロジェクトの目的を達成するために優れたツールを作る」ことを最優先にするプロジェクトを使いたいからだ。

ゲーム開発者に「ゲームを作りたいのか、ゲームエンジンを作りたいのか」と聞くようなものだね。ゲームエンジンを作るのもいいけれど、目標がゲームを作ることなら、エンジンを作るのは目標達成の方法として遠回りだ。

同じように、Bunの開発者はJavaScriptのより良いツールを作りたかったのか、それとも単にZigを使いたかっただけなのか、ずっと疑問に思っていたよ。

この記事は、AIによる自動書き換えが人間によって注意深く行われたことを示す上で、十分な配慮と規律が見られたと思う。それなりに安心感は持てたよ。

それはさておき、なぜ2026年になってもメモリセーフ（あるいはレースセーフ）な言語を使いたがらない人がいるのか分からない。Rustならパフォーマンスを維持したままそれを実現できるんだから、GCや不変性のパフォーマンス面を気にするとしても、Rustという選択肢があるはず。最高のパフォーマンスが必要でC++に落とし込む必要があるとか、単なる個人的な好みなら分かるけど、それ以外であればRustを選ばない手はないと思うよ。