BunのRust再実装はどのように進んでいるのか？

 (lockwood.dev)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 11日で完了した作業として知られているが、mainへのマージ後、6週間が経過した2026年7月27日時点でもリリースタグはなく、関連作業は続いている
  • 最初の再実装には、2026年5月3〜14日にAnthropic API費用16万5千ドルがかかったが、Buildkite CI/CDやその後の作業費用は含まれていないように見える
  • robobunのオープンPRは7月9日の1,277件から7月27日には2,475件に増加しており、PRごとのパイプラインが約40分かかるなら、すべてを処理するには86日間連続で実行する必要がある
  • 再実装開始とともにClaudeの使用量が急増し、robobunとAnthropic社員のRust作業への参加も増えているため、完了時期と実際の総費用を16万5千ドルと断定するのは難しい
  • Bunチームが再実装の完了や総費用を直接断定したわけではないため、AIコーディングの成果を企業価値評価の根拠にするなら、費用対効果と継続的な人手の介入まで見る必要がある

マージ後も続く再実装

  • Jarred SumnerはRewriting Bun in Rustで、2026年5月3〜14日の11日間にAnthropic API呼び出しへ16万5千ドルを使い、再実装の成果をmainにマージしたと明らかにしている
    • 1日あたり約1万5千ドルで、多くのオープンソースメンテナーには負担しにくい規模である
    • 組織のBuildkiteクラスターで継続的に実行されていたと見られるCI/CD費用は、この数字に含まれていないように見える
  • 2026年7月27日時点でマージから6週間が経過したが、新しいリリースタグはなく、最後のタグbun-v1.3.14からは11週間が経過している
    • 以前に1か月以上リリースがなかったのは、2022年10月26日のv0.2.2から12月7日のv0.3.0まで続いた6週間の空白だった
  • Claude Codeが作成したPRの代理指標であるrobobunのオープンPRは、7月9日の1,277件から7月27日には2,475件に増えた
    • Buildkiteの検査とmainへのマージにはおおむね約40分、時には1時間30分までかかることが観察されている
    • PRあたり40分を適用すると、2,475件をすべてマージするにはパイプラインを86日連続で実行する必要がある
    • 一部のPRはRustコードと関係がなく、個別のPRの中には非常に多くのレビューを経た例もある

公開されている費用と実際の投入の差

  • 再実装開始時点でClaudeの使用量が大きく増加し、その後もAnthropic社員とrobobunのRust作業への参加が増える流れが見られる
    • 分析には、再実装期間中のJarred SumnerのコミットがClaudeを使っていたという仮定が含まれている
    • 一部のPRはAnthropic社員が作成しているため、トークン費用だけでなく社員による直接的な関与も考慮する必要がある
  • 再実装が引き続き1日1万ドルずつかかると仮定すると、累積費用は約80万ドルに近づくが、これは公開された実費ではなく仮定に基づく推計である
  • Bunチームは、再実装が完全に終わった、あるいは総費用が16万5千ドルだけだったとは主張していない
    • この事例だけで、AIがオープンソースメンテナーの作業をより速く代替したと受け止めるのは難しい
    • Anthropicは自社ツールを社内で適用しており、自動化作業と社員の参加も続いている
  • AIそのものを否定するというより、現在の過度な期待と企業価値評価を警戒し、投入費用に見合う価値があったのか、その企業価値が正当なのかを検討すべきである
  • AnthropicのC compilerとCursorのFastRenderウェブブラウザは、数か月にわたってコミットがない

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker News の意見

  • Bun の Rust 書き直し版は 1 か月以上 Claude Code で運用されているが、ほとんど誰も気づかず、全体としてうまく動作している
    Bun v1.4 の動画で約束しただけの Node.js 互換性テストを通過するまではリリースしない予定で、関連 PR がマージされれば来週火曜日ごろに v1.4 をリリースする可能性が高い

    • ソフトウェア品質のためなら必要なだけ時間を使ってよい。1 か月リリースがないことは大ごとではなく、特定の機能が急ぎなら自分で貢献するかビルドすればよい
      Node.js もセキュリティ修正を除けば、毎年 12 月に 4〜6 週間ほど意味のあるリリースがないため、当事者に先に尋ねもせず怒った文章から始めた今回の批判は根拠が弱い。Node.js メンテナーとしての発言である
    • Claude Code 自体にバグやリリース後の障害が多いので、ユーザーが Rust ベースの Bun への移行で生じたバグと普段のバグを区別できなかったのも驚きではない
    • 記事で見積もっている費用、特に Buildkite の費用について答えてもらえるのか気になる
    • 多くの バイブコーディング・プロジェクトが勢いよく始まった後、Anthropic C のように放置されることがあり、Bun の将来を心配する理由は理解できる。Bun は速くて使いやすいので、GCC のように長く続いてほしい

  • 大規模なリファクタリングや書き直しの直後は、通常の開発速度を取り戻すのに時間が必要なため、コミット数とリリース周期だけで多くを判断するのは難しい
    開発者たちは構造に慣れていても Rust のコードベースには新たに適応する必要があり、ユーザー向け機能よりも unsafe の使用箇所の追跡のような作業に集中している可能性が高い。カナリアチャンネルでも大きな問題や変化はほとんど検知されていないため、急いでリリースするより滞っていた作業を処理する十分な理由がある
    Anthropic の C コンパイラと Cursor の FastRender ブラウザは、継続プロジェクトではなく能力実験だと見ており、今それを直接使っている人がいないことを願う

    • 1 か月前にすべての Claude Code ユーザーを新バージョンへ移行したので、ある意味ではすでに 本番リリースをしたとも言える。注目度が高い上に正式リリースを急ぐ必要がないため、段階的に進めているようだ
    • CI/CD コストという観点は興味深い。通常、AI の投資収益率に反論する際には、コードが多いからといって価値が大きくなるわけではないと言われるが、CI の実行ごとに課金するなら実際の売上は増える
      特に AI が作った反復作業が制御不能になるのを防ぐには、CI と追加テストが鍵になるという点とも重なる
    • 記事を書いた側としても、これらの数値でどれほど判断できるのか確信は持てない。次のリリース後に Anthropic や Bun が全体費用を明かす振り返りを出すことを期待している

  • LLM でプロジェクトを短期間に翻訳したり、オフィス製品の複製を一気に作ったりすること自体は驚くべきことだが、ソフトウェアの本質は速い初期生成ではなく、機能開発と長期保守にある
    Word の複製も基本機能はすぐ作れるが、ページ構造、表、画像、回転といった細部の機能から LLM は崩れ始める。SQLite を C から Rust に移してテストをすべて通したとしても、既存実装にある長年の最適化がないため遅い可能性が高く、言語移行に伴う新たなバグや今後のサポートも引き受けなければならない
    Reddit には X、Y、Z を実装したというプロジェクトが次々投稿されるが、バグ修正、ユーザー対応、セキュリティ、変化するデータ構造やデータベース作業は魅力的ではないため、バイブコーディングと同じくらい早く放置されがちだ
    自分が作ったソフトウェアを深く理解していなければ最終的に破綻し、X を Y 日で Z に書き直したという文句だけでは何の意味もない。開始を早めることと、移植されたコードを理解し、成長させ、保守することはまったく別のことであり、保守されている Zig 版の代わりに放置された Rust 版と宣伝めいた記事だけが検索結果を汚す可能性がある

    • この過程をもっと多くの人に記録してほしい。個人的に LLM への依存度が高いプロジェクトを作りながら学んでいるが、複雑な機能が素早く動くと強い快感がある一方で、統合、整理、UI の磨き込みは初期の速さを味わった後なので、かえってより苦痛になる
      コードがあまりに場当たり的に絡み合うと、LLM がより大きな混乱を起こさず前進できない 慣性点に到達し、アーキテクチャを直すか、すべて捨ててやり直すか、最後に正常だった時点まで戻す必要がある。ジェットパックを背負って開発するように、目標にも速く近づくが、壁にもより速く、より痛く衝突する
      AI が最高か最悪かをめぐる議論やツールの使い方競争に隠れて、何がうまくいき何が失敗するのか、利用過程で行動をどう変えるべきかに関する情報が不足している。自分でも利用記を書こうとしているが、新機能を作ったり UI の粗を直したりする方が楽しくて先延ばしにしている
    • GitHub には LLM 以前から、放置されたゲームエンジンや仮想言語向けコンパイラが何千もあった。2000 年代初頭の OS 掲示板でも、ほとんど全員が自分の OS を作っており、中には Firefox まで動かすものもあった
      すべてのソフトウェアが商用であったり完成度が高かったりしなければ有用でないわけではなく、学習用の実験だけでも十分に多くを学べる
    • 技術的に深くなるほど、代替可能だと見なされやすい。組織では、自分や人間関係ではなく純粋な技術力が価値を生むという前提を受け入れているからだ
      しかし ネットワーク効果、所有権、責任性のような偶発的要素も重要だという事実を受け入れ始めているようだ。ただし、多くの技術者がそうした要素にまつわる縁故主義、恣意的評価、技術よりも大言壮語が重視される環境を避けて技術領域に入ってきたという逆説もある
    • 大規模なコードベースで機能開発まで止めて完全に書き直したスタートアップで働いたことがあるが、別のプロジェクトを担当していたため過程全体を見逃した後で戻っても、学習曲線はほとんどなかった。言語は変わっていても 中核アーキテクチャ、データ構造、概念が同じだったからだ
      Bun も最初から再設計したのではなく、まず新しい言語にそのまま移した方式だ。LLM 以前の経験に照らしても、チームを素早く移行させるには、できるだけ単純かつ迅速に別の言語へ移すのが正しく、書き直し期間 X 日を最小化するのは良い目標だ
    • 自分が書いたコードを深く理解しない態度は 極端な短期主義である。メンテナーたちは、AI 生成コードと人間が保守できるコードの境界を苦労して学ぶことになるだろう

  • もともとの Zig 実装を誰かがモダナイズし、ベストプラクティスを適用してバグを直しながら、1秒未満のインクリメンタルビルドを達成したという。書き直しを正当化していた問題は、実は自ら作り出したもので、解決可能だったことを示唆している
    https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
    Zig 版も LLM を使っているので、文化戦争とは無関係だ。問題領域を正しく理解している人は、数十万ドル分のトークンのようなリソースを注ぎ込むだけの人より、常に良い結果を出せていた

    • 書き直しを正当化した核心はビルド速度ではなく、特にガベージコレクションで管理される JavaScript オブジェクトと相互作用するときに起きるメモリバグだった。Zig にはこれを一般的に防ぐ方法がなく、Buz が解決したという主張も見当たらない
    • このプロジェクトは真剣な試みというより、ミームや冗談に近く見える。既存の60万行を AI が作ったひどいコードだと断じ、大半のサブシステムを書き直すまで人間が書いた貢献を拒否すると明言している
      LLM でひどいコードを整理しながら人間の貢献は禁止する、というプロジェクトを真剣に受け止めるのは難しい

  • Bun の書き直しのおかげで、コードの移植や書き直し、外部依存関係のベンダリングをはるかに大胆に試せるようになり、上流プロジェクトには合わなくても内部要件に特化できるようになった
    コーディングモデルにより野心的な作業を任せる一方で、テスト装置と言語境界の外側での検証にずっと注力するようになった。数年がかりの大規模な書き直しにも関わったことがあるが、テストと機能の同等性を維持しながら改善まで加えた Bun は、途方もないエンジニアリング上の成功だと評価する

  • Bun の書き直しをめぐる議論には劇的な非難や個人攻撃が多く、それぞれがより深いイデオロギー的関心を投影しているように見える。この記事は、AI がプログラマーをどれほど成功裏に置き換えられるかに懐疑的であり、Zig メンテナーの論点は LLM 時代のオープンソース倫理と未来により近いものだった
    AI の能力を楽観視する立場からすれば、熟練開発者が最先端の LLM を導いてライブラリ全体を翻訳できることに、強く疑う理由はあまりない。より重要な次の問いは、現在のコストと、今後 AI の全面採用派と非採用派に分かれるのかどうかだ

    • チームにはRust 経験者が誰もいなかった
    • Bun の Zig→Rust 移植は、Zig、Rust、言語移植、LLM の使い方について、一般化できる教訓をほとんど与えてくれない。前後のコードベースには定量化しにくい特性が多すぎ、言語や移植方法、LLM コーディングに対する好みも介在する
      同じ結果が出なかったりトークン費用がより多くかかったりすればツールの使い方が悪かったと言え、結果が期待外れなら単なる概念実証だったし直近6カ月でモデルが良くなって比較できない、と逃げることもできるため、検証可能な結論を得るのは難しい
    • LLM はもっともらしく見えるが間違った結果を作るのに長けているため、懐疑的に見る理由は多い。今回の取り組みは、結果の真偽とは別に明らかなマーケティングイベントであり、Anthropic には誇張された、あるいは事実と異なる発表をしてきた前歴があるため、より厳密な検証が必要だ

  • 勝利宣言の発表と、率直に見えた詳細分析でさえ、いささか時期尚早だったのではないかと疑っていた
    LLM ブームの核心的なリスクは、タイピングや手作業での思考に疲れた熟練開発者に即時の成果を与える一方で、数十年にわたって積み上げられたソフトウェアの経験を担保に入れさせることだ。本当の請求書はずっと後になって届く

    • タイピングはソフトウェア工学では副次的なものだが、本当にタイピングがボトルネックになっている状況では LLM に価値があるかもしれない。ただし、そうした状況はまれだ

  • Rust ベースの Bun は6月17日から Claude Code で本番運用され、main に入った後はカナリア版としても提供されたという事実を記事に反映すれば、信頼性は高まるだろう。この規模の書き直しなら、長いカナリア期間は十分に正当化できる

    • 記事では Anthropic の内部での実利用をすでに扱っていた

  • Anthropic は次のバージョンを公開リリースすることに、あまり関心がないのかもしれない。Rust 版は1カ月以上、数百万人が使う Claude Code で稼働しており、Bun を買収した目的も Claude Code だった可能性が高い
    オープンソースプロジェクト自体は、彼らにとってそれほど重要ではないのかもしれない

    • 本当に Claude Code だけが重要だったなら、TypeScript ランタイムの言語を変えるより、Claude Code 自体を Rust で書き直すほうがはるかに効率的だったはずだ。約80万ドルの費用は、大きな宣伝効果を狙った Anthropic のマーケティング予算から出た可能性がある
    • より広いコミュニティを見捨てる可能性は低く、他のユーザーが多いほど Anthropic も利益を得る。今回のリリースで問題が起きれば強い批判を受け、コミュニティの信頼が損なわれかねないため、普段より慎重になっているようだ
    • Bun は Web エコシステムの主要構成要素なので、Anthropic が AI で開発しているという事実自体が巨大な宣伝効果をもたらす
    • Claude Code はどんな JavaScript ランタイムでも実行できるはずなのに、なぜ Bun が必要だったのか気になる
    • 結局、Claude ベースのコード書き直しを宣伝するためのマーケティングイベントに見える。不快なコードベースをなくしたいなら Anthropic に大金を払え、というメッセージはうまく伝わった
      Claude Code が目的だったならまずそれを書き直せばよかったし、もう直接コードを書かないと強調してきたのなら、実装言語も重要ではないはずだ

  • ソフトウェアを書き直したことがある人なら、今の段階を理解できる。大部分は動くが、回帰が出ないよう修正し続ける必要があり、リリースに伴うプレッシャーも非常に大きい
    書き直しの判断は正しかったと思うが、最初から本番環境にデプロイしたいとは思わない。Jarred がいきなり正式版を出すのではなく、リリース候補版から提供すれば負担を減らせる