Bunの将来性に少し不安を感じている件について

最近Bunを触ってみているけれど、エコシステムの安定性や今後の動向を見ていると、正直少し不安を感じる。みんなはどう思ってる？実際のプロジェクトへの導入について意見を聞かせてほしい。

全体的な前提に同意できないかな。買収される前から、Bunはいずれかの時点で収益化の方法を見つける必要があったわけだし。

今となっては、親会社が他のソフトウェア（Claude Code）でひどいやり方をしているとはいえ、それがイコールBunの質が下がることに繋がると考えるのは飛躍しすぎだと思う。不安になる気持ちもわかるけど、自分はまだBunに対して楽観的だよ。

特にこの2つの異なるコンテキストを考えるとね。Claude CodeはAnthropicにとって極めて重要なプロダクトで、急成長している分、ちょっとした変更でも課金周りのトラブルに直結する。一方でBunはJSランタイムであって、成長云々に関わらず「最高のランタイムを作る」ことに集中できる。課金やAnthropicの収益に直接響くわけじゃないから、Claude Codeと違って悪用対策で無理やりパッチを当てる必要もないしね。

今後数年でどうなるかは不透明だし、買収からまだ日が浅いから何かが変わるかどうかを見極めるには時期尚早だけど、今のところ自分は心配していない。

投稿者に同意する。一部の人には時期尚早に感じられる理由もわかるよ。

昔とは比べ物にならないほど世界は変わったし、今はみんな倫理的な懸念に対してより敏感で、過去の失敗を繰り返さないためにしっかりと自分の意見を主張しようとする人が増えてるからね。

技術的な観点から見れば早すぎるかもしれないけど、倫理的な観点からすれば理にかなってる。今の時代、一度起きた不正は以前ほど簡単にはうやむやにできないし、そういった決定が及ぼす大きな影響を避けるためには先制的な対策が必要なんだと思う。

AnthropicやClaude Codeの話は置いておいて、PerryTS1はBunのかなり有望な競合になりそうだよ。

著者は最後に、pnpmにはないBunの気に入っている点を列挙してるね。要するに、ネイティブなTSサポート、Viteスタイルのバンドラー、Vitest/Jestスタイルのテストランナーってことだけど。

バンドラー以外は、Nodeでもすでに全部できるよね。テストランナーの構文は違うかもしれないけど、それ以外はTSも普通にそのまま動くし、標準のテストランナーも十分使えるはず。Bunに対してここまで嘆く必要があるのかちょっと疑問だな。

Bunは元々、運営がうまくいっていた試しがないよ。どの機能もバグや穴だらけだったし、リリースするたびにいくつかは直るけど別のところが壊れるっていう繰り返し。

前回のパッチリリースで、大抵のソフトのメジャーバージョン2つ分くらいの破壊的変更や新機能をぶっこんできたこともあったしね。

自分は基本的にスクリプトランナーとnpmパッケージマネージャーとしてしか使ってないけど、「まともな」バージョンを探すためにどんだけ苦労しなきゃいけないか、本当に信じられないレベル。パッチバージョンでインストールがフリーズするなんてことが何度もありすぎて、そのせいでしばらくアップグレードできなかった時期もあった。たしか2マイナーバージョン前には、trustedDependenciesを使ったpostinstallスクリプトが完全に壊れてたはず。リリースノートに記載すらないし、なぜかGitHubのIssueでも報告されてなかったけど。1.1あたりまではpostinstallでBunにtrustedDependencyのビルドをやらせることができたのに、それ以降はできなくなったんだよ。リリースノートを確認したけど何も書かれてなくて、もう何ヶ月も壊れたまま。

さっき数時間かけて、ナイフ研ぎサイトのバックエンドをBunからNodeに移行し終えたところ。ベンダーロックインを回避できて気分がいいよ。最初はBunに熱狂してたけど、だんだん不安になってきてね。確実に恋しくなる機能はこれらだね：

• タグ付きテンプレートリテラルによるSQLiteのクエリ
• Bun.password.verifyのデフォルトがargon2なのは良い
• HTMLインポート
• JSXのトランスパイル
• .envファイルの自動読み込み

https://burlyburr.com (https://burlyburr.com) が https://backend.burlyburr.com (https://backend.burlyburr.com) を叩いてる構成だよ。

Bunの開発に携わっている身としては、この投稿は混乱する内容だな。私自身もBunチームも、毎日Bunを実際に使いながら（ドッグフード）、日々改善を続けている。開発スピードはむしろ上がっているし、Anthropicに加わってからBunの安定性は大幅に向上したよ。

次期バージョンでリリース予定のものをいくつか紹介するね：

• Windows x64バイナリのサイズを17MB削減 0
• Linuxバイナリのサイズを8MB削減 1
• 生成された子プロセスを再帰的に終了させる --no-orphans CLIフラグ 3
• クライアントTCPおよびUnixソケット向けのSSLコンテキストキャッシュ（Mongoose/MongoDBのようなDBクライアントのメモリ使用量を大幅に削減） 4
• fetchにおける実験的なHTTP/3 & HTTP/2クライアント 5
• Bun.serve()での実験的なHTTP/3サポート 6
• 組み込み画像処理ライブラリ Bun.Image [7]

（その他、node:fs、Worker、BroadcastChannel、MessagePortの信頼性向上もいくつか含まれる）

Anthropicの買収によって、Bunは収益を上げるビジネスにする必要がなくなった。Claude CodeがBunに依存しているし、多くのエンジニアがClaude Codeを仕事で使っているからこそ、Bunをより良くするモチベーションはすごく高いよ。

みんななんでNodeじゃなくてDenoやBunを使うの？JSランタイムの競合がいるのはいいことだと思うけど、Nodeから乗り換えるメリットが本当にわからないんだよね。BunにはREPLがないしJSエンジンも微妙だし、DenoはNodeに制限付きで面倒な権限システムを付けただけでSQLiteも使えない。両方ともパフォーマンスが良いって謳ってるけど、それは都合よく切り取られたベンチマークだけで、自分のテスト（まあ1年くらい前の話だけど）ではどっちもNodeに劣ってたんだよね。何か見落としてるのかな？

追記：思い出した。少し前に小さなERPツールを納品した時、Bunを使ったんだった。プロジェクトを *.exe にまとめるツールが一番強力だったから。確かにその点はNodeより体験が良かったよ。とはいえ依存関係なしのJSだったから、結局Nodeでコードを書いてBunでパッケージ化しただけなんだけどね。

買収前からBunがうまく機能してたとは思わないな。誤解しないでほしいけど、ちょっとしたスクリプトにはいつも使ってたよ。でも仕事で本番環境のサービスに使うなんて絶対無理。メモリ問題や修正されない非互換性が多すぎて、Node.jsの改善の余地を教えてくれる「おもちゃ」としては最高だったけどね。

例えば、このIssue（https://github.com/oven-sh/bun/issues/14102 ）を追ってたんだけど、結局どのライブラリも「もしBunならxを実行する」という分岐を入れる羽目になってて、これって互換性とは真逆の方向だよね。

この投稿はClaude Codeでの経験をもとにBunに「疑念を投げかけている」みたいだけど、少し回りくどすぎるんじゃないかな。Bunは隠されたソフトウェアじゃなくて、オープンソースとして活発に開発されてるわけだし。

だったらもっと直接的に、「買収されてからBunは実際どうなの？」って聞けばいいんじゃない？

今のところ見てる限り、以前と同じくらい速くユーザーに対応してるし、プロダクトも同じペースで改善されてるように見えるけどね。