BunのRust書き換えPRがマージ
(github.com/oven-sh)- PR #30412 は、BunをRustで書き換える変更で、2026年5月14日に
claude/phase-a-portブランチからmainにマージされた - 変更規模は 6,755件のコミット、2,188ファイル、
+1,009,257/-4,024行と表示されている - Jarred-Sumner は、詳細をまとめた ブログ記事 がまもなく公開されると明らかにした
- この変更は Bun の既存の テストスイート をすべてのプラットフォームで通過し、複数のメモリリークと不安定なテストを修正したと説明されている
- バイナリサイズは 3MB〜8MB減少 し、ベンチマークは中立的またはより高速な範囲だと説明されている
- 最も重要な理由として、チームが長年にわたり大きな開発・デバッグ時間を費やしてきた メモリバグ を、コンパイラ支援ツールで検出し予防できるようになったことが挙げられている
- コードベースは概ね同一で、アーキテクチャとデータ構造 もそのまま維持されていると説明されている
- Bun は引き続きサードパーティライブラリの使用を抑えており、async Rust は使っていないと明記されている
- ユーザーは
bun upgrade --canaryでこの変更を試すことができる - Jarred-Sumner は、問題が発生したら issue を上げてほしいと依頼し、スレッドが過熱した場合はロックする可能性があると述べた
- non-canary バージョンに入る前に、まだ 最適化作業 が残っている
- 整理作業もまだ残っており、これは後続の PR シリーズとして進められる予定である
4件のコメント
うわ、100万行級のPRがマージ。ZigからRustへそのまま一気に移行してますね。
これがマージされるかどうか分からないよ〜〜って話していたのに、たった1週間で、ちゃんと動いていたコードの言語を一発で置き換えるとは（笑）
なんだかAIアシストコーディングによって記念碑的な出来事が起きている感じ。
マジで、ただのテストで使わない可能性が高いって言ってたのに
Zigでやってくれないから、すぐRustに乗り換える大胆さよｗ
Hacker Newsのコメント
発表ではリライトに 1週間 かかったとされているが、Zig のイディオムを Rust のイディオムに対応付けるこの非常に詳細な指針ファイルを用意するのに、どれだけ時間がかかったのか気になる: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
しかも
Pointers & ownershipとCollectionsのセクションを見ると、Bun のコードベースはすでに内部スマートポインタ型を使っていて Rust の対応物に 1:1 でマッピングできるよう準備されていたし、bun_collectionsRust クレートもすでに存在していたこのリライトはかなり前から準備されていて、Anthropic 買収交渉中に Bun チームが提案したもののように見える
動いている金額が大きすぎるので、コミュニティに ステルスマーケター を紛れ込ませる誘因が明らかにあり、一部は単に陣営論理に陥っている
Anthropic が Bun を所有している以上、この作業を実際より簡単に見せたい誘因も十分にある
出力規模が非常に大きいので、ここには乗数効果があるように見える
ただ、このルールを作るためにどれだけの暗黙知が必要だったのか、このファイルをどれだけ反復的に改善したのかは気になる
たとえば、このルールのうちどれほどが変換の反復過程で遭遇した失敗例から生まれたのか知りたい
using internal smart pointer types that map 1-to-1 to Rust equivalentsと言っているが、スマートポインタ は Rust が発明したものではないポインタのある他の言語でコードを書くなら、すでに頭の中で同じ型をモデル化している
それに
bun_collectionsRust クレートがすでにあったというのは誤りだコードベース内の PR の一部にすぎず、以前から存在していたわけではない
疑念を減らし IPO ムードをさらに盛り上げるのは簡単なことで、AI を推し進めるために必要だった隠れた作業を別リポジトリで公開し、誰もが結果を再現できるようにすればいい
結局のところ顧客が実現したいのも「7日」で使える 100 万行のコードではないのか
みんなが自分のワークフローで再現しようとすれば Anthropic の利用指標も上がるだろう
本当に素晴らしい結果だったなら、リンクと手順付きのブログ記事を先に出していた気がする
まあ今この瞬間にブログ記事が書かれていて、私が間違っていると証明される可能性はあるけれど
それが陰謀論の核心なのか
bun_collectionsも移植ガイドよりずっと古いようには見えない+1009257 -4024とは、Bun はこれで Rust コード 100 万行 を超えたRust コンパイラ本体の規模に近づいている
ただし BunJS は大部分が JavaScript インタプリタのラッパーと NodeJS ライブラリの再実装、つまり Rust 標準ライブラリのラッパーに近い
BunJS は LLM 時代の ソフトウェア複雑性管理 を示すカナリアになりつつあるようだ
mostly a JavaScript interpreter wrapperは正確ではないBun はバッテリー同梱の JavaScript および CSS トランスパイラ（パーサ）、ミニファイア、バンドラ、npm のようなパッケージマネージャ、Jest のようなテストランナーであり、組み込みの Postgres、MySQL、Redis クライアントのようなランタイム API も備えている
当然ながらコード量は膨大になりうる
Bun は JavaScriptCore を JS エンジンとして使っているので、Bun 自体は JavaScript のパース、解釈、JIT を行っていない、少なくとも行うべきではない
修正: 読み違えていた。「JavaScript interpreter wrapper」と言っていたのでその表現で正しい
+のせいなのか他の要因もあるのかわからないが、モバイルでは 行数変更量 に下線が付き、タップすると電話をかけられるdiff のサイズが原因ならかなり面白い
リライト結果が近い LOC になるのは不思議ではない
$ rg 'unsafe [{]' src/ | wc -lの結果が 10428 で、$ rg 'unsafe [{]' src/ -l | wc -lの結果が 736 だった言語別では Rust 1443 ファイル 929213 行、Zig 1298 ファイル 711112 行、TypeScript 2604 ファイル 654684 行、JavaScript 4370 ファイル 364928 行、C 111 ファイル 305123 行、C++ 586 ファイル 262475 行、C Header 779 ファイル 100979 行とのこと
Zig では unsafe なコード はどうやって検索するんだろう
それとも単にどこにでもあると仮定するしかないのか
unsafeキーワードが入っているなら、良いリライトには見えないコードの半分近くが依然として unsafe なら、Rust にリライトする 意味 は何なのか
うちにあるもの:
10428まだこの件を扱うブログ記事を書いているところで、もっと詳しく共有する予定だ
背景が気になるなら Bun v1.3.14 とそれ以前のリリースノートにあるバグ修正一覧をざっと見るといい
Rust がこれらすべてを防いでくれるわけではない。参照を長く持ちすぎることによるリークや、JS 境界をまたいだ再入の問題は依然として自分たちで責任を負う必要がある
しかしその一覧のかなりの部分は use-after-free、double-free、エラーパスで解放を忘れる問題で、こうしたものはコンパイルエラーになるか自動クリーンアップに置き換わる
I work on Bun and this is my branchThis whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.もしかすると過剰反応ではなかったのかもしれない？
[0]: https://news.ycombinator.com/item?id=48019226
バグをふるい分けるために Zig と Rust のバイナリを幅広い実アプリケーションで並行実行したり、可能なら本番で シャドー実行 したりする計画があるのか気になる
おおよその見積もりは出せるのか
このリリースをユーザーのワークフローを壊さずに出すための具体的な計画も知りたい
およそ 9 日前、Jarred はこれがマージされるかまったく確実ではなく、過剰反応だと書いていた
皮肉だ
Linus が Linux カーネルをリライトしないと言っておきながら、ある日目覚めたら機械支援の Rust リライトを全部マージしていたらどれほどの騒ぎになったか想像してみてほしい
使った トークン費用 を正当化する必要があるのは明らかだった
うわ、今後見ていて面白そうだ
このコードがレビューされた可能性はまったくないが、もしかすると今やモデルがコードを書いてレビューするのを信頼できる ポストヒューマン時代 に入ったのかもしれない
これは Gastown っぽいが、はるかに有名なプロジェクトで起きたことだ
今後このプロジェクトがどうやって新機能を追加できるのか、そもそも追加できるのかが興味深い
Anthropic が Bun を具体的にどう使っているのか知っている人はいる？
Claude Code の一部なのか？
今後 Bun を使うのはかなり不安だが、その不安が Claude の利用にもどの程度当てはまるのかはよくわからない
自動言語変換を見抜ける テストスイート を信頼できないなら、そもそもそのテストスイートをまったく信頼すべきではない :)
自動変換を試すのは実際わくわくするが、後方互換性の問題 がたくさん起きそうで心配だ
コミットを見始めたが、基本的に「テストが通らない」問題をテスト自体を変えることで解決している
すでに配布されたプログラムで正しく動くようにする本当の作業は、これから始まるにすぎない
それでも救いなのは、サーバーサイド JS コミュニティがなぜかすでに頻繁な破壊的変更に慣れていることだ
だが、これが大きな問題なく本当に動くならかなり驚くべきことだ
GPT/Codex のほうがこの点では正直だ
このリライト全体に懐疑的だし、Jarred Sumner はネット上のフォロワーが非常に多いので広告のようにも感じる
素晴らしい！ テストに適当に
sleep(1)を追加するだけでいい。心配しなくていい、全部うまくいくさ！Bun を使っている数少ない自分のプロジェクトは別のものに移す予定だ
こういう 無謀な変更 を許すガバナンスは信頼できない
そもそもよく書かれているからリライトする必要もない
一方で 火の洗礼 がどうなるか見守るのは興味深いし、長期的には結局問題は解決される気もする
教育的に見る価値のあるスレッドがある。1 週間前に Jarred が再びマージ判断から距離を置き、すぐマージされると予測した人たちを大勢の歩兵が攻撃していたスレッドだ:
https://news.ycombinator.com/item?id=48073680
今見ると、うまく持ちこたえられなかった発言だったな？
これが少しでもうまくいかなければ、自分の商品に酔ったドラッグディーラーという嘲りが延々と暗い形で続くだろう
Mythos の論文を読んだことがあるか？ 擬人化が本当にひどい
ただの安っぽい注目集めなのかもしれないが、本気で LLM に意識があると信じているなら……すごい話だ