Bunの実験的なRust再実装版がLinux x64 glibcで99.8%のテスト互換性に到達
(twitter.com/jarredsumner)- BunのRust再実装版は、Linux x64 glibc環境で既存のテストスイートの**99.8%**を通過
- コードベースは「基本的に同じコードベース」であり、Rustへの移行によってコンパイラが型のライフサイクルを強制し、必要なタイミングでデストラクタを使えるようになった
- 安全でない部分はRustのunsafeとしてより明確になり、リファクタリングを促す効果がある
- 再実装の理由は、メモリリーク、クラッシュ、安定性の問題を心配し修正することに多くの時間を費やすのに疲れ、言語がそれを防ぐより強力な手段を提供してほしかったため
- 全体規模は960,000 LOCの再実装と表現されており、Linuxでテストスイートを通過し、他のプラットフォームもまもなく対象になる予定
Rust再実装の状況
- BunのRust再実装版は、Linux x64 glibc環境で既存のテストスイートの**99.8%**を通過
- コードベースは「基本的に同じコードベース」であり、Rustに置き換えることでコンパイラが型のライフサイクルを強制し、必要なタイミングでデストラクタを使えるようになった
- 安全でない部分はRustではunsafeとしてより明確に現れ、リファクタリングを促す効果がある
- 再実装の背景には、メモリリーク、クラッシュ、安定性の問題を心配し修正することに多くの時間を使うのに疲れ、言語がこうした問題を防ぐより強力な手段を提供してほしかったという理由がある
- 全体規模は960,000 LOCの再実装と表現されており、コードは実際に動作し、Linuxでテストスイートを通過しており、他のプラットフォームもまもなく対象になる予定
今後公開される内容とビルドに関する回答
- Bunにとっての意味、ベンチマーク、メモリ使用量、今後の保守性、実際の再実装プロセスは別のブログ記事で扱う予定
- 再実装プロセスは単に「claude, rewrite bun in rust. make no mistakes」としたものではなく、最後まで動く状態に到達するための作業は6日前から始まった
- 手作業だったなら膨大な作業量になっていただろうと表現されている
- コンパイル時間は、より高速なZigコンパイラを使う既存のZig版と基本的に同程度であり、upstream Zigコンパイラを使っていたならRust移植版のほうがより速くコンパイルできただろうとしている
- パフォーマンスは別のブログ記事で扱う予定
- libc自体をRust版のfrankenlibcに置き換える次の段階については、その前に自前でlibcを作るつもりだとしている
1件のコメント
Hacker Newsの意見
4日前にもこの話は出ていた: https://news.ycombinator.com/item?id=48019226
Bunの開発者が自分のブランチだと言っており、当時のスレッドは動かないコードへの過剰反応で、まだ書き直しを確定したわけではなく、コードが丸ごと捨てられる可能性も高いとしていた
実際に動く版がどうなのか、性能と保守性がどうか、Bunのテストスイートを通すのがどれだけ難しいのかを確認して、Rust版とZig版を並べて比較したいと言っていた
cargo checkで16,000件以上のコンパイラエラーが出ており、バージョン番号の表示もJavaScriptの実行もできなかったこんなに早く動くとも、性能がここまで競争力を持つとも思っておらず、詳細はブログ記事になる予定とのこと
Anthropicに買収された後なので予想すべきだったが、それでも失望している。大規模言語モデル技術そのものに反対しているわけではないが、こうした「AI」企業がソフトウェア産業と社会全体を食い物にしながら権力を得たやり方は不快で、非常に不健全な依存を生んでいる
数手先を見据えて、スロップのないソフトウェアスタックとコミュニティを準備すべきだ。そこにはZigとそのエコシステムも含まれる。私たちや将来世代がスロップなしで完全に生きられないとしても、自由としての自由を備えた持続可能なコンピューティング文化を守ることは、これまで以上に重要だ
これをこんなに短期間でやり切ったのは非常に印象的だ。同じようにTypeScriptをRustへ移植するプロジェクトを5か月やっているが、Mythosも無制限トークンアクセスもない
それでもほぼ100%近い通過率まで来ており、執筆時点で99.6%だ: https://tsz.dev
Rustは大規模言語モデルでコードを書くのにかなり向いている。厳格な型システムのおかげで、他の言語なら通ってしまうような非常に間抜けなミスを減らせる
ただし、大規模言語モデルでコードを書くからといって、プロジェクトに必要な設計ビジョンやトレードオフ判断が不要になるわけではない。だからJarredとチームは、大規模言語モデルを使って膨大なコードを活用しながら書ける適任者だ
一方でRustは複雑な言語なので、小さな変更が離れた箇所のリファクタリングを強制するリファクタリング雪崩が起きやすい。初期アーキテクチャが悪い、または不十分だと、大規模言語モデルがよくやるようにコードベースを段階的に膨らませるほどスパゲティ化する危険が大きい
結局コンパイルも実行もできるが、人間には読めず保守もできないプログラムになるのではと心配している
Mythosなしで、月200ドルのCodexアカウント8個が使える範囲が全てだった
Rustの利点はここでも感じていて、Postgresの経験を踏まえると、人々が長年pgで苦労してきた複数の箇所に対して良い設計判断を下せると見ている。AIによって、以前なら現実的でなかった複雑なソフトウェア改善がより可能になるのは楽しみだ
[0] https://github.com/malisper/pgrust
[1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
きれいな境界を保ったり築いたりすることすら、没入状態ではなく苦しいレビューになり、結局は先延ばしモードに入ってしまう
強い根拠があるわけではないが、もうBunには関わりたくない。直感に近いが、信頼も支持もできない
LLM書き直しを活用するためにZigをフォークし、Zigチームが明確に嫌がっていた非決定的コンパイルのようなものまで作った
今は不満げにRustでLLM書き直しをしている。Zigの設計哲学が難しくても正確な判断を強制したからこそ今の位置まで来られたのかもしれず、Rust書き直しが没落の始まりである可能性も現実にある
技術というより政治に近い判断だが、BunはClaudeに完全に支えられているように見える。Anthropicの次のマーケティング文句が「Claude Mythosが先進的な950K LOCのJSランタイムをRustに書き直し」でも驚かない
リンク先のTwitterスレッドは明確な技術的根拠を示している
JS/NPMエコシステムで働くというのは、すでに検証されていない依存関係への純粋な信頼に大きく頼ることを意味しており、LLM書き直しの前後で違って見えない。元の目標とAPI契約を満たしているなら違いはあるのか。そもそも既存ソースコードを丁寧に読んでいたのかも疑問だ
毎回、既存の競合をより良く、より速く、より強く圧倒するといった調子だったが、Keep It Simple Stupidだけは絶対にやらないことがあまりにも明白だった
近い将来に実運用環境で目にするのは、加速剤をかけられたように一社ずつ燃え尽きるYCスタートアップばかりになるのも明らかだった。今やもう引き返せない地点を過ぎたように思える
Anthropicは自分たちの「性能」問題を解決しようとする、やや愚かな試みとしてBunを買った。そもそも問題はひどいコードにあったと分かっていなかったようだ
それでも実際に有能な開発者たちを連れてきたので、ある程度の助けにはなったかもしれない
しかしその過程で、Bunは公開プロジェクトというよりAnthropicの社内ツールに近づき、今はAI資金に過保護に支えられながらかなり焦点を失っている
バブルが弾けたとき、Bunに注がれた努力の一部でも回収できることを願う。Anthropicが長期的に保守するとは思えない。彼らはランタイムサポートを売る会社でもなければ、傍らでランタイムを維持できるほどGoogle級の規模でもない
AIの関与をいったん脇に置けば、良い変化だと思う
BunはZigを使っていてクラッシュやメモリバグが極端に多く、RustベースのDenoとは違っていた
もちろんBunのRust移植に
unsafeが多ければ、魔法のように全部解決するわけではないが、それでも改善はするだろう醜い部分が
unsafeとしてより明確に見えるのでリファクタリングを促す、という点は、言語だけの問題ではなくBun自身がある程度招いた面もありそうだもしそうなら、そのようなツールで高品質ソフトウェアを作るのは事実上不可能ということにならないか。C/C++でも品質の高いものは多く作られてきたのに、Zigは何を間違えているのだろう
unsafeとして明示されるので見つけやすく、解決すべき課題の一覧が自然にできるこれに6日かかった。最終的に意味のある結果にならないとしても、今後トークンと仕事量がどう結び付くかを示している
より多くの計算資源を持つ個人や企業と競争するのは難しくなるだろう。彼らは私にはできないことをそのままできてしまう
完成したコードベースを例として使い、テストスイートで検証できるなら、望む目標に向かって反復するのはずっと簡単だ。モデルは目標が何か、そして一度実装されたやり方が何かをすでに見られるので、仕様から始めるよりはるかに簡単な問題になる
資本を投じて、よく理解されたスケーラブルな手法で作り、電気を差せば価値が出る
要するに、現代世界で電気がそうならなかったように、「持てる者と持たざる者」に分かれる可能性はないということだ
今見えているのは「わあ、これで俺は10倍エンジニアだ！」と言いながら、より多くのコードを吐き出しているが、明確な方向性や美意識はない姿だ。現時点での大規模言語モデルベースの仕事の大半は、ただのノイズに見える
Qwen 3.6 27bを使ったことがあるか分からないが、サイズのわりにできることが異常だ。コンテキスト管理をうまくやれば、小さなプロジェクトなら100%バイブコーディングも可能だ
こうしたモデルも計算資源と同じく、結局は価格競争で下がっていくだろう
これを額面通りに受け取る人が多いが、かなりの部分は以前から構築されていた標準以上に広範で包括的なテストスイートのおかげで可能になっている
後でマーケティングするなら、この速度を可能にしたテストスイートを設計し、キュレーションするのにどれだけの人間の労力が入ったのかも一緒に書いてほしい
テストスイートは現世代の大規模言語モデルにとってほとんど理想的な環境として機能する。十分に包括的なテストスイートは、エージェントが望む形で実装できる仕様になり、ここではその対象がRustだった
Bunのようなプロジェクトでテストがよくできているなら、場合によっては実際のソースコードをすべて捨てて、テストだけにアクセスさせても、全体を最初から再実装できる気すらする
責任の一部がテストスイートにもあるなら、それがRust移植に対して何を意味するのかも気になる
それを可能にした元のアーキテクチャとテストスイートに費やされた数十万時間は無視しろということか
AIを使ったRust移植の注意事例として見る価値がある
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...
Claude code Cコンパイラはgccテストを100%通したが、
hello worldすら実行できなかった論理テストだけを与えれば、速度はまったく考慮しない。速度を測るテストを含めて性能を合わせろと言えば、それもやるようになる
大規模言語モデルの他の誤りと同じ種類だ。人間が重要だと思うことについて常識的な文脈を持たない。境界を強制しない限り無視する
生きている時代が本当にすごい
業界と職業の根本的なダイナミクスが、あまりに短い時間で、ほとんど一夜にして変わってしまった
ある日は、今の自分にできることがあまりに増えたので興奮する。欲しいものはほとんど即座に作れ、ソフトウェアで夢見ていたことの100%が現実になりうる
ある日は、雇用市場に何が起きるのかが怖い
急に、非常に少ないもので非常に多くを得られるようになり、世界が必要とするソフトウェアの量には限界がある
ソフトウェア販売を中核事業モデルにしているすべての会社は潰れるのだろうか?
最高のモデルに特定の会社や政府だけがアクセスできるようになったらどうなるのか?
10億トークンを持つ企業100社が、1000億トークンを持つ専門ベンダーより良い製品を作れるだろうか?
「ロゴ生成器」のようなソフトウェアベンダーやSaaSはすでに死んだも同然だが、次世代の大規模言語モデルにチケッティングシステムが内蔵されない限り、チケッティングシステムのベンダーは大丈夫だろう。人員は減るかもしれないが、確実ではない
流れ込む人の数に比べて分け合う仕事があまりない、といった語りで、崩壊がその物語を強化した
しかし当時学生だったとしても、ソフトウェアの射程は事実上無限だと分かったはずだ。私たちが手作業でやっている認知的作業のほとんどすべてはソフトウェアでできる。一度そういうものを列挙しようとして、やるべきことがあまりに多いとすぐに気づいた
しかも、仕事を新しいやり方でやるほど、想像もしなかったさらに多くの仕事が生まれることも理解した。可能性は数え切れず、「飽和」という物語はソフトウェアが何であるかについての想像力と理解の不足から来ているのは明らかだった
だからこの分野は決して飽和しないと分かっていた。ソフトウェアで作る対象が尽きることなど不可能だったからだ
だが最近は違う。これからも新しいソフトウェアは作り続けるだろうが、今は、私たちが新しくやることを想像する速度よりも、ソフトウェアを書く速度のほうが速くなりうるのではないかと考えてしまう
一般大衆も最前線より遅れたモデルで自分たちを助けることはできるだろう
少なくとも、こうした試みが進むのを眺めるのは興味深い
まず気になるのは、そもそもテストスイートの網羅性と品質がどの程度なのかという点だ。難癖をつけたいわけではないが、全プラットフォームで100%が出たとしても、Bunチームが移行にどれだけ確信を持てるのかは気になる
先週のUbuntu coreutilsの件で、99.8%テスト互換のRust書き直しに対する印象が本当に悪くなった
ここでリンクされているツイートを開いたら身震いするような感覚があり、今ではこういうものを見ると正反対の感情が湧く。ほとんど出口を探している気分だ