BunのRustリライトに関する私の考え

Andrew Kelley - BunのRustリライトに関する私の考え (2026年7月9日) BunのRustリライトに関する私の考え 背景: BunをRustで書き直す 歴史 Jarred氏が約5年前にZigコミュニティに参加したとき、私は彼を強い「初心者エネルギー」を持っている人物だと評しました。つまり、彼は速く動き、様々なことを試しましたが、まだ解決する能力のない問題に飛び込み、エンジニアリングの観点からは平凡な結果に終わるものの、その過程で多くのことを学びました。私はこれを、特に若者や学生にとって非常に健全な姿勢だと見ています。これがレベルアップし、新しいことを学ぶ最良の方法です。 彼がBunに注力するにつれて、注目を集めるようになりました。JavaScriptは世界で最も人気のあるプログラミング言語であり、有望な新しいツールチェーンには多くの潜在的な注目が集まります。この注目は、いくつかの異なる方法で活用された可能性があります。例えば、彼はサンフランシスコの基準であっても、クラウドファンディングを通じて十分に生計を立てることができたでしょう。しかし、大学ではなくThiel Fellowshipという考え方の学校を卒業した彼は、本質的に幼い頃からシリコンバレーの考え方を無批判に受け入れるように育てられ、ベンチャーキャピタルを受け入れました。 当初から、Jarred氏はZigプロジェクトに感謝していました。彼はBunのウェブサイトで、プロジェクトのパフォーマンス上の成果をZigのおかげだと credit していました。彼はZig Software Foundationに年間6万ドルに相当する月額寄付を設定しました。彼はどちらも行う必要はありませんでしたが、そうし、それは非常に素晴らしいことでした。私が参照している彼のブログ記事でさえ、彼はZigプロジェクトに対する感謝の念を表明しています。 しかし、BunがVC支援のスタートアップになると、彼はゴールラインに向かってレースを始めました。今や、無料のオープンソースプロジェクトに取り組んでコミュニティと共に学び成長するのではなく、Jarred氏はビジネスを運営していました。 この時点で、彼が突然マネージャーになったとき、この「初心者エネルギー」は私にとって異なる意味合いを帯び始めました。自分自身のために悪いワークライフバランスを選択することは一つのことですが、他人にそれを要求することは全く別のことです。「Ovenは、特に最初の9ヶ月ほどは大変な作業になるだろう。ワークライフバランスが、働いていない時間を多く過ごすことを意味するのであれば、それはおそらく適切な選択ではない。」 豆知識：人々は互いに話します。私はOvenでの仕事に面接した人たちと話しました。そこで働いていた人たちとも話しました。それらの人々はお互いに話しました。誰もが皆と話しました。噂は大きく健全で、ジューシーなブドウで満たされていました。そしてそれらのブドウはすべて同じメッセージのジュースを含んでいました：Jarredはひどいマネージャーだった。コミュニケーション不足、非現実的な期待、共感の欠如、経験不足。雇用という観点からは、全くの最悪の状況でした。 その結果、Zigコミュニティのメンバーは給料をもらってZigでコーディングする仕事を見つけることに熱心でしたが、才能のある人材のほとんどはOvenやBunを避けました。同時に、ZigとJarred氏との間の亀裂が広がり始めました。生産性への彼の単一の焦点と彼のスタートアップの出口戦略は、Zigプロジェクトに対する私の長期的なビジョンとますます対立するようになりました。彼は、私がより大きな計画を持っていたにもかかわらず、私のすべての他の優先事項を捨てて、Language Server Protocolの実装とVSCode統合に取り組むように私に繰り返しせがんだことを覚えています。 しかし、主な問題はコードの品質でした。Zigチームは定期的にユーザーのプロジェクトをチェックしています。私たちは言語がユーザーにどのように影響しているかを知るためにソースコードを読み、問題のある破壊的な変更がどの程度影響するかをテストし、パフォーマンスの低下をチェックします。私たちはBunのコードベースで見られるプログラミングの実践にますます愕然としました。ハックの上にハック。アサーションの乱用。何よりも、反省とバグや技術的負債の解消にほとんど時間をかけずに、機能から機能へと無謀に突き進んでいました。 Jarred氏は、LLMにアクセスするずっと前から、すでに下手なコードを書いていました。今、ユーザーが何をするかを警察のように取り締まるのは私たちのビジネスではありませんが、メモリ安全性について人々が絶えず私たちに叫んでいることに気づいたかもしれません。人々が批判を浴びせることに熱心な、その無責任なソフトウェアエンジニアリングの実践がまさにその種の批判を招くプロジェクトから、私たちがどのように社会的な距離を置きたいと思うかを想像できるでしょう。 私たちは彼らをより良いプログラミングの実践に導こうと futile な試みをしました。機能不全の会社で最善を尽くした数人の例外的なヒーローがいました。あなたは誰か知っています。しかし、あなたは高まる潮を止めることはできません。 この時点で、私たちZSFの全員がBunは純粋な負債だと感じていました。そしてこれはRoboBunがナンバーワンの貢献者になる前でした。Zigプログラミング言語の公に想定される代表的な例が、実際にはZigコードの書き方 "How Not To Write Zig Code" の主要な例であることが、不快感とともに、いつか彼らは売却するだろう（正直に言って、彼らの曖昧な "クラウド何かを売る" ビジネスプランは最初から茶番だった）、私たちは間接的に否定的な評判を受け、その定期的な寄付を受け取らなくなるだろうということでした。 だから、Anthropicによる買収が最終的に起こったとき、私たちZSFは安堵のため息をつきました。寄付が静かに止まったとき、私たちの銀行口座はそれに対応する準備ができていました。彼らは私たちとの月例会議をキャンセルしませんでしたが、現れませんでした。私たちは驚きませんでした。関係は終わりました。壁には（書き直し）の兆候がありました。 わずか数日以内に、私たちはRustのリライトが来るだろうとすでに疑っていました。そして私たちはそれを応援していました！ 大規模なAI企業による買収は負担でした。なぜなら、ClaudeがBunで書かれ、BunがZigで書かれているという間接的なつながりさえも、単にスロップ（質の低いコード）の貢献の急増を引き起こしただけでなく、Zigコミュニティへの無味乾燥なAI愛好家の流入も引き起こし、LLMの出力をフォーラムの投稿に貼り付けることが反社会的であることを彼らに伝えなければならなかったからです。一瞬、私はZigのアイデンティティが、AIに関連付けられたプログラミング言語として俗に知られるようになるのではないかと恐れました。 Jarred氏がRustリライトを発表したとき、私たちは大喜びしました。それはあまりにも良い話のように思えました。正直に言って、私はその技術がこの偉業を成し遂げるのに十分だとは思っていませんでした。しかし、彼はそれをやり遂げ、今、私は比喩的に "もう私の問題ではない" と書かれたマグカップから美味しいお茶をすすっています。 ブログ記事への言及 ブログ記事は巧みに書かれています。まるで1兆ドル企業のマーケティング部門がこの記事に多額のお金をかけているかのようです。しかし、いくつか異論があります。 ここでは、バグを回避するために "スタイルガイド" またはプログラミング言語の機能のいずれかを選択しなければならないという二項対立が提示されています。このすり替えは、読者をバグを排除する主な方法からそらしています。それは、それにエンジニアリングリソースを投入することです。あなたはTigerBeetleに十分な credit を与えていません。単純に、彼らはバグを見つけて排除するために時間を費やし、ZSFとの良好な関係を維持するよう努めていますが、Bunはそうしませんでした。 レビューされていない100万行のコードをすべて出荷するという議論は、テストスイートがすべてを捉えるのに十分だということです。では、なぜZigコードに多くの厄介なバグがあると言っているのですか？テストスイートがすべてを捉えるのに十分だったというのはどうなったのですか？それはZigコードのバグを捉えるには十分ではありませんが、レビューされていない100万行のひどいコードのバグを捉えるには十分なのですか？ パフォーマンスの向上はLTOに起因するとされていますが、これはBunの存在期間中ずっとZigがサポートしていました。以前はデフォルトで有効になっていましたが、LLVMのバグが多すぎることが判明しました。それらのバグはすべてRustにも影響します。私たちはあなたにそれを有効にすることを試みるように言ったかもしれませんが、あなたは聞きませんでした。私たちは良いアドバイスをしているのです、ちくしょう！ 記事では、Zigコードのファジングを行っていると主張していますが、私たちの通話中、Bunチーム全体が何もファジングしていないと私たちに伝えました。これは明白な捏造のように見えます。 ブログ記事は、"BunはRustの方が優れている" という主張をより良くするために、バイナリサイズを削減するために行われた多くのエンジニアリング作業を概説していますが、そのエンジニアリング作業はすべてリライトとは無関係でした。私はこれがブログ記事が長引いたまさに理由だと思います。