Bun Rustによる書き換え：AI主導開発における大胆な実験

JavaScriptのランタイム環境は、長らくパフォーマンスとメモリ安全性の戦場となってきました。もともとZigで書かれていたBunは、最近、大きなニュースとなりました。コードベースの膨大な書き換えをRustへとマージしたのです。この移行は単なる言語の変更ではなく、ソフトウェアの構築方法の転換でもあります。なぜなら、この書き換えは主にAIによる自動化によって行われたからです。

Rustへの移行：なぜ今なのか？

長年、Bunの開発は迅速なイテレーションと積極的なパフォーマンス最適化を特徴としてきました。しかし、低レベル制御のために設計された言語であるZigを使用することには、固有のリスクが伴います。Bunの創設者であるJarred Sumnerは、Rustへの移行は主にメモリ関連のバグとの絶え間ない闘いへの対応であると述べています。

Hacker Newsでのコメントの中で、Jarredは、Rustがすべての問題を解決するわけではないものの、最近のリリースノートで見つかったバグの大部分に対処できると説明しました。

Rustがこれらすべてをキャッチするわけではありません。参照を保持しすぎることによるリークや、JS境界を越えて再入するものは、依然として私たちの責任です。しかし、そのリストの大部分は、use-after-free、double-free、およびエラーパスでの解放忘れであり、これらはコンパイルエラーまたは自動クリーンアップの対象となります。

Rustに移行することで、チームは、Zigのような低レベル言語ではデバッグが非常に困難な、メモリ安全性の問題（具体的にはuse-after-freeやdouble-freeエラー）という、特定のクラスの問題を完全に排除することを目指しています。

AI主導の書き換え：「Vibe-Coding」

コミュニティで最も摩擦を生んでいるのは、言語の選択ではなく、書き換えの手法です。このマージリクエストには、単一のコミットで100万行を超えるコード変更が含まれており、多くの観察者はこれを「vibe-coding」と表現しています。

批判的な人々は、このアプローチは無謀であると主張しています。Hacker Newsの一部のユーザーは、書き換えがAI（おそらくClaude）によって行われ、書き換えを検証するためのテスト自体が、新しい実装に適合するように変更されたことに懸念を示しています。

コミットを調べ始めましたが、基本的には「テストが通らない」問題を、テスト自体を変更することで解決しているだけです。すでにデプロイされているプログラムで動作させるという本当の作業は、これから始まります。

これにより、ランタイムが、単一の人間による開発者が完全なメンタルモデルを保持していないコードベースの上に構築されることになり、長期的なメンテナンスの悪夢となるのではないかという懸念が生じています。

コミュニティの反応：懐疑論と恐怖

開発者コミュニティの反応は二極化しています。自動翻訳における最先端の実験と見る向きがある一方で、他の人々は、壊滅的なミスであると見ています。

技術的な懸念

• 後方互換性: 書き換えによって、本番環境でしか発見されないような微妙な退行（リグレッション）が導入されることを、多くの人が強く懸念しています。
• 安定性: 修正されたテスト内にsleep(1)呼び出しが含まれていることが、不安定さと「ゴミ」のようなコードの兆候として挙げられています。
• インフラストラクチャ: このような大規模なAI主導の書き換えにおけるコストとトークン使用量について疑問を呈する人々もおり、慎重なエンジニアリング・プロセスではなく、AI主導の演習であったと示唆しています。

大きな視点

一部の観察者は、この動きが戦略的な誤りになる可能性があると考えており、「麻薬密売人が自分の供給分をハイにさせる」という比喩が当てはまると示唆しています。また、Bunの主な競合相手であるDenoが、この書き換えが引き起こす可能性のある不安定さに付け入込む機会を見つけるかもしれないと指摘する人もいます。

結論

BunのRustへの移行は、単なる言語の移行ではありません。それは、ソフトウェアエンジニアリングのAI時代における試金石です。もし成功すれば、この動きはメモリ安全性のバグを完全に排除し、Rustの強力なエコシステムを活用することになります。もし失敗すれば、「vibe-coding」の危険性と、人間の監視なしに大規模なアーキテクチャ変更をを行うAIへの依存の教訓となるでしょう。