Bunの将来とRustへの書き換えに関する議論の要約である。Anthropicによる買収後、Claude Codeの不具合やそれに伴うBunの将来への懸念が広がっている現状を解説する。また、JaredによるZigからRustへの大規模なコードベース移行の理由、その手法、およびunsafe多用による技術的負債のリスクについて詳細に分析している。
Bunの現状とRustへの書き換えについて
Bunは私の心にとても近い技術です。私がこうしたコンテンツ制作を始めてからずっと、ジャレッドとは友人関係にあります。私が自分の番組にゲストを呼んでいた頃、彼は最初のゲストの一人でした。そして、Bunがスタートして以来、その進化をずっと愛してきました。私はBunとチームの熱烈な支持者であり、彼らがAnthropicに買収される前の最後のイベントでも登壇したほどです。しかし、彼らを応援したい気持ちと同じくらい、最近Bunを使い続けるのが難しくなっていると感じていました。そして、そう感じているのは私だけではありません。Open Codeのダックスは最近、Bunを離れてNode.jsに移行するという大胆な決断を下しました。彼はWindowsでの安定性から、Electronとの互換性、さらには別プロセスを起動する必要がないことまで、幅広い理由を挙げていました。しかし、最大かつ最も重要な問題は、Bunの将来に対する不確実性です。そして、そう感じているのはダックスだけではありません。Bunの将来についてウィリアム・ジョンソンが書いた素晴らしい記事があります。彼らはRustで書き直しを行っているのです。ジャレッドによると、Bunの既存のテストスイートの99.8%が、Rustへの書き換えにおいてLinux x64のglibc上でパスしているそうです。Bunは最大のZigプロジェクトの一つとして有名であり、おそらく最も関連性の高い最大のプロジェクトでしょう。Zigは非常にクールな言語ですが、あらゆる種類の目新しい問題や、奇妙なコミュニティの課題、そしてBunチームとZigチームとの間の少し変わった関係性も抱えています。そして、BunがRustで書き直されるというかなりクレイジーな膠着状態に陥っているようです。エージェントが並行して動作し、Bunのようなものを書き直せるかを確認するための楽しいサイドプロジェクトとして始まったものが、はるかに実現可能なものになりつつあります。これが最終的にマージされてリリースされなかったら、私は驚くでしょう。BunはZigをフォークした状態から、あっという間にRustで自分自身をフォークする状態へと移行しました。彼らがどのようにこの決断を下したのか、この変更を実現するために構築したパイプラインなど、面白い詳細がたくさんあります。これらのAIツールを使用してソフトウェアを移行する方法について、学ぶべきことが数多く存在します。しかし同時に、人々がBunに対して抱いてきた正当な懸念もあり、この移行がその一部を解決するとはいえ、必ずしもすべてを解決するわけではないという現実もあります。Bunの未来はかつてないほど明るい一方で、かつてないほど恐ろしいものにもなっています。ここでは掘り下げるべき詳細がたくさんあります。このBunのフォークについて話す前に、今日のスポンサーのために少し話題をフォークさせてください。
スポンサーメッセージ：WorkOS
今日のスポンサーについてはすでにお話ししたことがありますね。WorkOSです。彼らは認証プラットフォームを提供しています。おそらく、皆さんのプロジェクトの大半では彼らを必要としないでしょうし、私も同じようにアドバイスするはずです。私にもたくさんの異なるプロジェクトがありますが、そのほとんどでWorkOSを使っていません。しかし、そこに問題があります。プロジェクトがうまく行き始めると、ほぼ間違いなくすぐに後悔することになるからです。テオさん、自分で認証を実装するのは簡単ですよ、と言われるかもしれません。確かに、1つか2つのサインインボタンを追加するだけならそうでしょう。しかし、誰かがあなたのサイトにスパムを送り始めたらどうなりますか。WorkOSに組み込まれているRadarのようなものがなければ、その人が単なるボットなのか、それともあなたのサービスを悪用しようとしているOpenClawのインスタンスなのかを知ることは困難です。もし人々がそういうことをしているなら、単にMCPを出せばいいじゃないか、と思うかもしれません。では、そのMCPをどうやって認証するのでしょうか。歴史的に見て、認証はMCPを正しく機能させるための最も難しい部分の一つです。WorkOSはサービスの一部としてMCPの認証を組み込んでいるだけでなく、サンフランシスコでMCPに関する最高にクールなイベントであるMCP Nightも主催しています。私はMCPの大ファンではないことで有名ですが、本当にクールなイベントなので、これまでのMCP Nightにはすべて参加してきました。もし5月21日にサンフランシスコにいるなら、絶対に参加を検討するべきです。本当に楽しいですからね。でもテオさん、大企業はみんな独自の認証システムを構築していますよ、という声も聞こえてきそうです。ええ、OpenAI、Cursor、Vercel、Baseten、Carta、Webflow、Vantaのような大企業のことですね。ご存知の通り、私たちは現実世界に生きており、現実世界において認証は自分たちで構築するには重要すぎます。認証のバイブコーディングをやめて、soyv.link/workosで安全にリリースを始めましょう。
Zigの課題とBunが抱える問題
さて、Rustで書かれたBunについて話す時間です。私たちが乗り越えなければならない問題には、大きく3つのレイヤーがあります。まずZigに関する問題があり、次にBunに関する問題、そして最後にあらゆるものを書き直すことに関する問題です。この件にはたくさんのレイヤーが重なっています。まずはZigから始めましょう。できるだけ簡潔にお話しします。Zigのエコシステムについて私が耳にしてきたことは、すべて少し奇妙なものでした。この言語は信じられないほど強力で、多くのことにおいて素晴らしいのですが、他の言語には見られない形でC言語の後継のように感じられます。特に、特別なコメント構文を使用してコンパイラがコードを生成する方法を変更できるコンパイル時の機能などは魔法のようです。コンパイル時にバイナリ出力を調整できる能力は、マルチプラットフォームから他のシステムとの統合に至るまで、あらゆる場面で非常に役立ちます。彼らが組み込んだこの魔法のような機能は、実にクールなトリックを可能にしてくれます。しかし、これらの魔法のトリックはフットガン、つまり自滅を招く危険性とも見なされ得ます。そうした強力な機能と、プログラマに必要なことを何でもやらせてくれるという性質上、本質的にはメモリ安全ではない言語を組み合わせると、メモリリークやセキュリティ問題などの潜在的なリスクを大量に抱え込むことになります。そして、もともとLinux向けに構築されたものをWindows上で動かそうとするなど、マルチシステムをまたぐ領域に入るとさらに厄介です。幸運を祈るしかありません。そして多くの人がBunでまさにその問題に直面してきました。Bunは信じられないほど素晴らしいですが、問題を抱えています。私自身、Bunとメモリ管理に関する驚くほど多くの問題に遭遇してきました。特にAdvent of Codeのようなことをしているときなどです。特にBunの初期の頃は、頻繁にメモリの境界の壁にぶつかっていました。安定してからは意味のあるレベルで改善されたことに気づきましたが、それはWindows上で使っていない限りにおいての話でした。Windowsでは本当に散々な目に遭いました。また、Bunと自分のコードの両方をコンパイルされた実体に含めることで、多くの異なるシステムで実行できる単一のバイナリとしてJavaScriptコードを簡単にバンドルして配布できる点にも注目する価値があります。これがClaude Codeなどの配布方法です。Claude Codeのバイナリをインストールすると、Bun自身を含む実行に必要なすべてのものがバンドルされています。これは現在、Open Codeのようなツールが構築されている方法でもあります。しかし、それはつまり、これらのすべてのツールが、特にWindows側においてBunと同じ問題の数々に苦しめられていることを意味します。ダックスが公に共有しているように、彼はBun固有のAPI、具体的にはこの場合BunのファイルAPIから移行するという退屈な作業に取り組んでいました。Bunを使うと、Node.jsの同等品よりもはるかに高速で洗練されており、しばしばよりエレガントなbun.file APIを呼び出すことができます。Node.jsのファイルAPIは控えめに言っても疑問が残る代物です。ありがたいことにBunはすべてのNode APIもサポートしているため、それらを呼び出すことができ、シムでラップされているため適切に機能するはずです。しかし、Open CodeチームはBun固有のAPIを使用することを選択したため、Bunから離れたいと思った今、かなり困った状況に陥っているのです。ここでジャレッドがWindowsの安定性の問題についてコメントを寄せてくれました。Bun 1.3.10以降でもまだ問題が発生しているのか気になるとのことです。実際にWindowsでClaude Codeをそこそこ使っている人間として言わせてもらうと、Bun 1.3.10には間違いなくまだ安定性の問題が存在しています。
Open CodeのダックスがNode.jsへ移行した理由
先ほどお話ししたように、ダックスはなぜこの移行を行っているのかについて多くのことを語っていました。彼によると、NodeはWindowsでより安定しているとのことです。彼らは現在、Windowsで多くの痛みを味わっています。Electronのデスクトップアプリはそれを簡単に埋め込むことができます。後で少し話す様々な理由から、Bunの将来について確信が持てないのです。Nodeへ移行することで、Denoを自由に探索する選択肢も得られ、人々がOpen Codeを自分たちのアプリに埋め込むことがより容易になります。これは非常に過小評価されている強力なユースケースです。そして彼らがベンチマークを行った結果、Bunのわずかなパフォーマンスの優位性から実際の恩恵は受けていませんでした。これについては私も以前から言っていました。ランタイムの処理において、Bunのパフォーマンス向上は人々が思っているほど劇的なものではないと。パッケージ管理については信じられないほど素晴らしいです。開発者として自分のマシンで実行するために実際にバンドルする用途にも信じられないほど素晴らしいです。コードをバンドルしてリリースした瞬間、それは最高のものになります。しかし人々はしばしば、Webサーバー上で1秒間に何千ものリクエストを処理する環境において、Nodeがいかに強力でBunがどれだけ速くなれるかを過小評価しています。それでも、ここで話しているのは、可能な限り多くのリクエストを1秒間に処理しようとした場合でも、せいぜい3倍程度の違いに過ぎません。Expressを使うとNodeでの約2万からBunでの約6万になります。確かにそれは巨大な数字です。明らかにその方がずっと良いですし、3倍の速さです。しかし、それは1秒間に2万リクエストという規模での3倍の速さです。もしローカルエージェントのコードでその恩恵を受けているなら、それはひどいコードを書いているということです。
Anthropic買収後の懸念とClaude Codeの現状
ウィリアム・ジョンソンのこの記事はさらに踏み込んでいます。全文を読むつもりはありませんが、興味がある方のために説明欄にリンクを貼っておきますね。Bunは素晴らしいソフトウェアであり、私はいつも使っています。高速で実用的ですし、チームは絶えずリリースを行っています。すべてのアイデアを手に入れることができますし、Bunには勝ってほしいと思っています。真剣なNodeの代替品が欲しいですが、Bunの未来が心配です。Anthropicは2025年12月の時点でBunを所有しています。そして彼らは、あなたが聞きたかった言葉をすべて言ってくれました。オープンソースであり、MITライセンスを維持すること。同じチームが開発を続け、ロードマップは引き続き高性能なJavaScriptツールに焦点を当てること。また、Claude Codeが数百万人のユーザーに向けてBunの実行可能ファイルとして配布されていることにも言及していました。もしBunが壊れれば、Claude Codeも壊れます。AnthropicにはBunを素晴らしい状態に保つ直接的なインセンティブがあります。12月の時点ではこれは心強く聞こえましたが、Claude Codeが崩壊しつつある今となっては、それほど心強くは感じられません。Anthropicは今でも素晴らしいモデルを作っています。これはAnthropicを批判するだけの投稿ではありません。まあ、完全にはそうではないという程度ですが。Claude Codeはかつて素晴らしかったのです。1年前は本当に信じられないほど素晴らしいと感じました。去年の12月でさえ、私はClaude Codeに深く恋をしていました。しかし、物事が悪化し始めているように見えてきました。Bunの買収は、実際には彼らがそれをより良くするために行おうとしていたことのように感じられました。Bunにとってもはるかに良いことでした。なぜなら彼らにはそれを利益化する現実的な方法がなかったからです。私はジャレッドと彼らの選択肢について詳しく話し合いましたが、どれも良いものには思えませんでした。しかし今、Claude Codeはひどい状態です。世の中には良いコーディングエージェントがたくさんあります。T3 Codeがここに含まれているのは嬉しいですね。私たちはエージェントではなく、他のエージェントやシステムのラッパーなので、厳密には当てはまらないと主張したくはなりますが。T3 Codeを使えば、CursorやCodex、そして間もなくOpen Codeでも使えるようになり、さらには背後のエージェントとしてPiやClaude Codeと組み合わせて使うこともできます。言及してくれたのは嬉しいことですが、皆さんまだであれば絶対にT3 Codeを試してみてください。私たちがこれほど多くの労力を注ぎ込んだのには理由があります。本当に素晴らしい体験を提供できるからです。著者はCursorを使うのをやめなければならず、数ヶ月ぶりにClaude Codeに戻ったところ、以前には見られなかったほどひどい状態になっていることに気づいてショックを受けました。ここのセクションはとても興味深いですね。Anthropicはエンジニアリングのポストモーテムを公開し、デフォルトの推論エフォートの低下、古いセッションのバグ、そしてコーディングの品質を損なうプロンプトの変更など、プロダクトレイヤーの問題を非難しました。ポストモーテムには感謝します。何も起こらなかったふりをするよりはマシですからね。正直なところ、Anthropicが自らの責任について言及したのはこれが初めてだったかもしれません。それから、OpenClawの騒動もありました。ああ、あれは完全にめちゃくちゃでしたね。彼は私のクリップまで引用しています。コミットメッセージに特定の文字を入れるだけで、単純なclaw-p highコマンドが請求のエラーやルーティングの異常を引き起こす可能性があることを示したクリップです。これは教科書通りのエンシッティフィケーションです。変更をリリースする前に、実際のコードレベルの体験を誰も慎重にドッグフーディングしていないように感じられますし、間違った方向に進んでいるように思えます。それが現在、著者がBunについて心配している理由であり、ある程度私自身も心配している理由です。BunはClaude Codeに埋め込み可能です。Claude Codeはエンシッティフィケーションが進んでいるように見えます。ですから私は今、Bunもエンシッティフィケーションするのではないかと心配しなければなりません。Bunが悪いからではありません。Bunは悪くありません。Bunは素晴らしいです。Bunチームが気にかけるのをやめたからでもありません。私はそんなことは信じていません。問題は、BunとそのチームがAnthropicに統合されるにつれて、彼らの方針も統合されていくということです。Claude Codeの崩壊を招いたのと同じ方針です。チームが自分たちの製品をドッグフーディングすらしていないように見える問題がBunでも発生し始めるのでしょうか。私にはわかりませんが、念のために使い続けたいかどうか確信が持てません。ええ、多くの人が動揺しており、その理由はすべて完全に理解できます。私自身も十分に多くの問題に直面してきたため、いつも遭遇する様々な楽しいエッジケースがあるパッケージ管理については、私たちをBunからT3 Codeへ移行させることを検討しているくらいです。
大規模なRustへの書き換えと技術的負債のリスク
とはいえ、一般的に言ってRustへの移行は理にかなっていると思います。これまでなら絶対に意味がなかったような、この手の大胆で退屈な作業を行うために、モデルをこのように押し進めるのを見るのは本当にクールです。しかし、私はこの種の完全な再設計が全く新しいカテゴリーのバグを生み出し、それがClaude Codeのバンドルや配布に影響を与えないという理由で迅速に対処されないのではないかと懸念しています。そしてここで、すべてを書き直すことに関する問題に行き着きます。たとえば問題のセットがあるとしましょう。これがBunにおける10個の課題だと仮定します。これらの課題のうち、こちらのいくつかはパッケージ管理やモノレポ固有のものだとします。ですからこれらをモノレポのバグと呼びましょう。これらは、私たちがパッケージ管理のためだけにBunを使っているT3 Codeで対処しているようなものです。そしてここにある残りのすべてはランタイム環境のものであり、仮の話ですが、これらはClaude Codeに影響を与えます。もし現在Bunに10個の課題があり、そのほとんどがここにあるClaude Codeに影響を与えるセクションにあり、パッケージ管理のためにBunを使用している大きなモノレポを持つ人々に影響を与えている、その外側に存在する課題がいくつかあるとしたらどうでしょうか。現在のBunチームはどちらに焦点を当てていると思いますか。彼らがClaude Codeに直接影響を与えるものに焦点を当てるのは明らかだと思います。Claude Codeをそれほど悩ませていない反対側のバグの優先順位が下がっていることにはすでに気づいています。では、この書き換えを行ったらどうなるでしょうか。Bunの10個の課題がBunの100個の課題になり、彼らがこの書き換えを行いながらBunに影響を与えるすべてのバグに対処し続けるため、この分割の割合が50対50に近づくように短縮されたとします。私の最大の懸念は、反対側に新しいタイプの技術的負債が蓄積されることです。Bunチームがより一般的なユーザーをターゲットにしようとしていた時に直面した問題であったため、書き換えの前は壊れていなかったものたちです。現在、Bunが存在し資金提供を受けている主な理由がClaude Codeのサポートである以上、こうした新しい問題が本来受けるべき優先順位を決して得られないという事態が起こり得ると考えています。そして、それは私が抱く現実的な懸念です。Bunチームが注ぎ込むすべてのテスト、すべての作業、すべての労力が、Claude Codeが必要とするパスが十分にサポートされていることを確認することに向けられた場合、それ以外のものはどうなるのでしょうか。そして、コミュニティのフォークがこの問題を解決するのに十分だと考えている人は、Node.jsの歴史にあまり注意を払っていません。これほど複雑なものにおいて、コミュニティのフォークは非常に困難です。幸運を祈りますが、それは起こらないでしょう。これは私の中の理想主義者が折り合いをつけなければならないことです。プロジェクトを運営している人々は、多くの人々が直面しているバグではなく、自分たちの本業に影響を与えるバグに焦点を当てる傾向があります。ええ、極めて現実的です。
Zigフォークの歴史とAIを活用した驚異的な開発スピード
書き換えについてさらに深く掘り下げる前に、ジャレッドがこれについてどのように考えているかを話したいと思います。彼が以前言っていたように、Rustの書き換えにおいて、Linuxのコンパイル環境ではBunの既存のテストスイートの99.8%がパスしています。基本的には同じコードベースですが、コンパイラに型のライフタイムを強制させることができるようになり、必要なときにデストラクタを使用できるようになりました。そしてあちこちにunsafeがあるため、醜い部分はさらに醜くなっていますが、これはリファクタリングを促すものです。それから、理由の核心部分があります。メモリリークやクラッシュ、安定性の問題を心配し、その修正に多くの時間を費やすことにひどく疲れてしまいました。これらの問題を防ぐためのより強力なツールを言語が提供してくれたらどんなに素晴らしいでしょう。ここでジャレッドが言葉にはしていないものの、暗に含まれていると私が主張できるのは、彼自身がすべてのコードを書いていたときは、自分がコードを書いていたため、同じようにそれらのことを心配する必要はなかったということです。それが彼が開発に取り組んでいた時のレベルであり、それらの細部に注意を払っていました。彼がチームを運営するマネージャーとして、しかしここではより重要なこととして、多くのエージェントを走らせる人物として、より抽象化された立場になった今、彼が現在いるこの抽象化のレベルでは、もはや現場の泥臭い作業をしていないため、これらの詳細について考えることが難しくなっています。そして、それにかかる労力はかつてないほど高くなっており、実際の変更を加えて現実の問題を修正しようとしているのに、もはやそれらの問題が発生するレベルで作業していないときには信じられないほど苛立たしいものです。これは本当に過酷です。彼はこの変更に関する詳細なブログ記事を計画しています。これがBunにとって何を意味するのか、ベンチマーク、メモリ使用量、今後のメンテナンス性、そして文字通りそれを実行するプロセスについてです。なぜなら、ClaudeにBunをRustで書き直してと頼んだだけではないからです。誤解しないでください。これは96万行のコードの書き換えです。コードは本当に機能しています。Linux上でテストスイートにパスしており、間もなく他のプラットフォームでもエンドツーエンドでパスする予定です。彼は6日前にこれに取り組み始めました。手作業で行えば膨大な作業量になっていたはずです。その通りですね。彼らはまた、以前BunのZigフォークにおいて公式のBunアカウントに投稿していました。Zigが行っていなかったことを修正するためにZig言語をフォークしたからです。彼らはMacとLinux上のLLVMバックエンドに、複数のコード生成ユニットでの並列セマンティック分析を追加しました。これにより、Bunのデバッグビルドのコンパイル速度が4倍になり、内部の開発スピードが向上しました。その結果、新しいリリースであるBun 1.3.14が登場しました。そしてジャレッドは自身の個人アカウントでも、もしRustへの書き換えをマージする場合、これがZigでの最後のバージョンになるだろうと述べており、この新しいバージョンが間もなく実現することを示唆しています。ここでチャーリーが反論しているのがすごくいいですね。あなたがこれを試していることは素晴らしいと思います。もし私があなたの立場だったらと考えると一つ恐れているのは、200の既知の問題を、ユーザーが時間をかけて発見することになる未知の数の未知の問題と交換しているのではないかということです。どのようにして自信を持ってこれをリリースするのですか。ええ、まさにその通りです。私が先ほどこの図を描いていたのはそのためです。いつものようにあなたに完全に同意します。チャーリーが私の200%同意できないことを言ったのを見た記憶がありません。テストスイートにパスするのは素晴らしいことですが、素晴らしいテストスイートでさえプログラムの動作の一部しかカバーしていません。そうでなければバグなど一つも存在しないはずです。ええ、ジャレッドもすべてのテストにパスしていると言っています。彼らが抱えているこの200以上の課題でクローズされています。彼はまだZigの実装よりも遅いベンチマークを見たことがありません。基本的には同じコードベースです。それは重要な詳細です。それは基本的には同じコードベースなのです。非同期Rustは使用しておらず、Zigの実装と同様にサードパーティのライブラリはほとんど使用していません。本当に同じものですが、クラッシュを防ぐためのより良いツールが備わっているだけです。誰かがTokioを使わないのかと尋ねたところ、彼はそれは事態を悪化させるだろうと返答しました。このフォークのブランチがClaudeのブランチであるという点も最高ですね。
Rustコード内のunsafe呼び出しの多さについて
ここでいくつか確認したいことがあります。最初に確認したいのはclocの実行です。コードの行数を数えながら、彼らがこの中でunsafeを何回書いているかを確認したかったのです。もしご存知なければ説明しますが、Rustの最もクールな機能の一つはボローチェッカーです。これはコンパイル時のチェックであり、アプリケーションのグラフ全体にわたってメモリを割り当て、使用する方法が安全であることを証明します。あるものがメモリにアクセスしているとき、コードレベルでそれがそのメモリを使用している唯一のものであることを検証します。これはRustを非常に複雑にしている要素の一つです。Rustのコンパイル時間がこれほど遅い理由の一つでもありますが、Rustを信じられないほど安全な言語にしている要素の一つでもあります。メモリ安全なマシンレベルのコードを書くことができるのです。安全でなければコンパイラが怒ってくれますからね。しかし、そこからの抜け道が存在します。unsafeキーワードです。人々はunsafeをTypeScriptのanyのようなものだと考えているようです。概念的にはそうかもしれませんね。unsafeが存在する主な理由は、ボローチェッカーのチェックやRustのメモリ安全性の性質をオプトアウトし、コードを書きやすくするため、またボローチェッカーが適切に尊重しない可能性のあるものを回避するためです。そして一般的に言えば、unsafeの呼び出しを多くするべきではありません。参考までにuvを取り上げてみましょう。ご存知ない方のために説明すると、多くの点でBunに相当するPythonのツールです。パッケージおよびプロジェクトマネージャーであり、pipの代替品に近いですが、超クールです。先ほど引用したチャーリーはuvのクリエイターです。彼らは現在、彼らを買収したOpenAIにいますが、これは非常に理にかなっていました。しかし比較のために言えば、彼らのプロジェクトは完全にRustで作られています。98.1%がRustで、少しのPythonが含まれています。結局のところPython用のツールですからね。ここにどれだけのunsafeが存在するか見てみましょう。RSファイルだけをチェックします。さて、uv全体で36ファイルの中に165個のunsafeのインスタンスがあります。チャットのジョンが言ったこの表現が好きです。unsafeは乱用されがちです。本来は、安全であることを証明できるけれどコンパイラには証明できない小さな抽象化のために使用すべきなのです。ええ、ありがたいことに彼らはuvのすべてにおいて165回しかそれを行う必要がありませんでした。訂正します、これにはコメントなどが含まれています。この数字は完全に正確ではありませんが、チャットの指摘によると常に括弧を後ろに付けるべきだそうです。ですからunsafeの後にスペースと括弧が続くのは、uv全体で73回発生しています。uvは35万行のRustで書かれており、その全体で70回程度のunsafe呼び出しがあります。BunのRustへの書き換えはまだ進行中です。68万1000行のRustと571,000行のZigがあります。Rustコードは同量のコードであるにもかかわらず、コメントの数が2倍以上あることにも注目する価値があります。実際には3倍近くありました。AIがそれを書いたことがわかりますね。しかし、このコードベースにはunsafeがいくつあるのでしょうか。uvの数字が素晴らしかったので、これは2倍ほどの大きさのコードです。はっきりさせておきましょう、unsafeの呼び出しは1万3044回です。これが問題を適切に強調してくれることを願っています。彼らは実際にはRustを書いていません。Rustの構文でC++を書いているのです。このコードが問題なく、unsafeを適切に使用している可能性も十分にありますが、彼らはそうしていません。ジャレッドの言葉に戻りましょう。基本的には同じコードベースなのです。これは重要です。彼らはRustのやり方ですべてのレベルを適切に解決するために、Rustでゼロから書き直しているわけではありません。彼らはZigのコードを1行ずつRustに移植しているのです。そしてそのZigのコードはボローチェッカーによれば安全ではなかったため、彼らは単にあちこちにunsafeを放り込んだのでしょう。最終的にはこれを減らすことができます。そして私は実際に、これがどこに向かうのかについての幸福な道筋を見ています。もしメモリリークに気づき、そのメモリリークが始まる関数を見つけたら、エージェントに、ねえ、この関数はunsafeだ、これをunsafeじゃなくして、と伝えることができます。問題を引き起こしている呼び出しをすべて追跡し、ここにunsafe呼び出しを置く必要がなくなるようにするのです。事実上、彼らはメモリの安全性を強制することを選択した箇所から、ツリーの任意の下層に向かって安全性を強制するためのツールを手に入れていることになります。しかし、どこかにunsafe呼び出しがある瞬間に、それはある程度、その上下のすべてを汚染してしまいます。ですから、それらが1万3000以上もあるというのは少し恐ろしいことです。特に彼らはまだ半分ほどしか終わっていないのですから。
TypeScriptのGo言語移植から学ぶアプローチ
ここで反例を一つ挙げたいと思います。皆さんは私のことをおかしいと思うかもしれませんが、少し話を聞いてください。TypeScriptのGo移植です。TypeScriptのGo移植はTypeScriptの移植版です。歴史的に、そのTypeScriptサーバーはTypeScriptで書かれてきました。そうしなければならなかったようなものです。tscはJavaScriptのすべての奇妙な動作を網羅する必要があり、JavaScriptなしでそれを行うのは困難だからです。それが、TypeScriptをJavaScriptに変換できるツールはたくさんあっても、型が正しいかどうかをチェックするツールがこれまで存在しなかった理由です。TypeScriptのGoプロジェクトが始まるまで、型チェッカーは常にTypeScriptの中にしかありませんでした。彼らの解決策、そして彼らが特にGoを選んだ理由は、既存のTypeScriptコンパイラをGoで1行ずつ書き直したかったからです。彼らは当初、コードモッドを使用してTypeScriptの構文をGoの構文に変換し、できるだけ多くのコードを引き抜いて最初の一歩として機能させるというところまでやりました。Goの構文は柔軟であり、率直に言って愚かであるため、その大部分を行うことが可能だったからです。彼らはZigやRustを含む他の言語も検討しましたが、特にGoを選びました。その構文がTypeScriptに十分近かったため、意図的かつ完全に最適ではないことを承知の上で、Goの強力な並列化機能などを一切使用せずに1行ずつの移植が可能だったからです。ネイティブ言語であるというだけで、既存のコードを1行ずつ書き直すプロセスにより、コードはより速くなりました。それ以来、彼らはさらに先へと進み、Goを特に素晴らしいものにしている要素を活用してより直接的に最適化を始めています。しかしそれまでは、ただ1行ずつ書き直しているだけであり、基本的にはGoのコードではありませんでした。Goで書かれ、Goによってコンパイルされ、代わりにネイティブバイナリとして実行されるTypeScriptのコードだったのです。この考え方は機能し得ます。言語を言語として、つまり世界とコミュニケーションをとる方法として考えることから脱却しようとし、代わりに言語をコンパイラに何をすべきかを伝える方法として扱うと、根本的に異なる方法で考え、構築することになります。そして私は、AIが現在この種の思考スタイルをさらに促進していると思います。私たちが以前のように細部まで執着して学ぶ対象として言語を扱うのではなく、実行されるものを生成するためにコンパイラに渡されるものとして扱うようになっているのです。GoはTypeScriptチームが愛する言語ではありません。Goは彼らがより良いパフォーマンスを発揮するコンパイル済みバイナリを作成することを可能にするツールなのです。同じように、RustはBunチームが愛する言語ではありません。彼らが純粋にZigを愛していることは明らかです。Rustは、彼らが現在不満を抱いている特定の種類のバグを防ぐために必要な、適切なツールを備えているのです。そして繰り返しますが、AIにそれをやらせているなら、エージェントに、ねえ、このunsafe関数が問題を引き起こしている、これをunsafeじゃなくして、ボローチェッカーのエラーにぶつからなくなるまで実行し続けて、と伝える方がずっと簡単です。これは実際の問題を解決できる可能性のある、実行するための強力なループです。現在ジャレッドが解決しようとしている問題には、エージェントが問題を再現するために全体を実行することなく実際に解決できるほど、十分に優れたフィードバックループがありません。現在では仮の話ですが、Rustのコンパイルチェックを実行し、何がパスして何がパスしないかを見るのと同じくらい簡単です。そしてRustのエラーメッセージは非常に優れており、TypeScriptの開発者として嫉妬を覚えるほどです。もしそれらのエラーメッセージをエージェントに渡すことができ、何らかの形で読み取ることができるなら、BunへのAIによる貢献やAIによるバグ修正ははるかに容易になったと言えます。
移植における技術的課題とAIモデルの限界
ここにはジャレッドからの別の考えもあり、読み上げてみたいと思います。Rust移植で厄介なことの一つは階層化です。現在は多数のクレートになっており、コンパイル時間は短縮されますが、循環依存がブロックされます。BunのZigコードベースの多くは、イベントループタスク、プロセスの終了コールバック、ノンブロッキングファイルIOなどのインターフェースにタグ付きポインタを使用しています。トレイトはこれに対する慣用的なRustのアプローチのようですが、トレイトはコストがかかります。コンパイル時やLTOを通じて非仮想化されることはありません。Zigの関数ポインタについても同じです。パッケージを分割しなかったのでこれは問題になりませんでしたが、コンパイル時間を短くしたいですし、理想的にはBunの一部をクレートとして公開し、他の人がBunのすべてを取り込むことなく使用できるようにしたいと考えています。コンパイラとリンカーに見える形で、ランタイムやメモリのオーバーヘッドコストがほぼゼロになるようなより良いアプローチを、Rustの経験がある方に提案してもらえないでしょうか。現在のRustコードが行っているのは、リリース時に各タイプに対して外部のRust宣言を生成するマクロを使用し、単一のコード生成ユニットを構築してLTOを有効にし、共有ライブラリを持たずに、リンカーのLTOに依存してそのタグに基づいてインライン化と直接関数呼び出しを行うというものです。これは機能しているようですが、一般的ではなく乱雑に聞こえます。より良いアプローチはあるのでしょうか。彼はこれをやりながらRustの内部構造を学んでいますが、彼がこのような情報を共有してくれるのを見るのはクールですね。また、移植でここまで進みながら、パッケージングについての考え方や、根本的なレベルでコードベースをどのように分割するかを覆す意思があるというのはかなりクレイジーなことです。なぜなら、彼らはMythosにアクセスできるため、Mythosをループで実行できるからです。彼らにはそれができるのです。このコードの多くがMythosによるものであっても私は驚きません。実際、その多くがMythosによるものでなかったら驚くでしょう。このプロジェクトを通じて彼らが頻繁に直面する課題の一つは、コンパイル時間の問題を回避することだと私は考えています。Rustのコンパイルは特に速いわけではありません。多くのクレートに分割することは役立つ方法ですが、循環参照を壊すことや、Zigにあるような適切なコンパイル時のプリミティブを持たないことなど、彼らの前には楽しい問題が待ち受けています。これがどのように進むのか興味があります。全体として、この投稿が「いいね」の数では多くの反応を得たにもかかわらず、返信が非常に少なかったという事実は、この知識がいかにニッチであるかを示しています。そしてAIエージェントはまだ、これらのことを理解できるほど賢くありません。これは低レベルな問題における最高難易度の課題です。幸運を祈ります。実際、私は彼らの成功を祈っています。これはちょっとクレイジーなことです。でも1万3000回のunsafe呼び出しもかなり頭がおかしいですね。
これからのBunに期待すること
心配している方のために、ジャレッドのこの言葉で締めくくりたいと思います。明確になっていないといけないので言っておきますが、最終的な結果がパフォーマンス、メモリ使用量、そしてもちろん安定性の点でZigの実装よりも目に見えて優れていない限り、Rust移植をマージする可能性はゼロです。安定性が最優先だからです。過去にジャレッドの現在の雇用主には痛い目を見させられましたが、私はジャレッドを今でも信頼しているので、彼の言葉を信じます。彼は良き友人です。彼は身を粉にして働いています。これが最終的にどこに行き着くのかを見るのが楽しみです。これは超大胆な書き換えです。私たちが毎日構築しているシステム全体をAIを使って書き直したらどうなるか、というような、最も公の場で行われている試みの一つです。そしてもし彼らが、Bun全体が書かれている言語を1ヶ月足らずで変更することに実際に成功したら、それはかなり画期的なことです。TypeScriptのGo移植がだいたい1年ほど経ち、それが公になる前にもかなりの期間開発されていたことを考えれば、私たちは時間をとってこれを評価するべきだと思います。これはジャレッドとチームが引き受けたかなりクレイジーなプロジェクトであり、私は彼らに大きな敬意を払っていますし、今でも彼らが成功することを願っています。これがどうなるかは全くわかりませんが、このようなことが起こるのを見るのは興奮します。私たちが利用できるテクノロジーを使って、もっと多くの人々がこのような大胆な飛躍に挑むのを見る必要があります。なぜなら、そうすることで私たちが使っているものの限界や、私たちが日々どのように構築しているのかを知ることができるからです。この移植が素晴らしいものになり、結果としてすべてが改善されると私が思っているかですか。もしかしたらそうなるかもしれませんが、おそらくそうはならないでしょう。私はこれが実現するとは思っていますし、恩恵もあると思っています。問題も生じるでしょう。そして間違いなく、私たちは皆その結果から多くを学ぶことになると思います。皆さんがどう感じているか気になります。これは彼らがMythosを試しているだけの小さな楽しいプロジェクトなのでしょうか、それともこれからの私たちの考え方を変えるような本格的な書き換えなのでしょうか。私は今まで以上に色々なことを考えていますし、皆さんもそうであることを願っています。それでは次回まで。
コメント