bunを何回か使ってみたけど、すごく楽しかった！ノードより全然いい。ただ…！bunでいつも行き詰まって、結局ノードに戻っちゃった。最初はcryptoモジュールがNode.jsの署名と互換性がなかった（今は修正済み）、次はPlaywrightがCrawlee経由でbunと動かなくなった。

でも最近のNodeにも内蔵サーバーやSQLiteがあるよね？それとも、もっと多機能が必要なら、Honoがいいよ。

これについてみんながどう思ってるのか、すごく気になる。私にとって、Nodeは成熟していて、民主的で、コミュニティ主導のプロジェクトって感じがする。特に数年前のio.jsフォークのドラマをうまく乗り越えた後はね。bunもdenoも、どちらもVC資金で運営されてるから、コミュニティ主導の民主的なプロジェクトではないのは明らかだよね。

問題の一部は、変更がかなり漸進的で、NodeJSに戻すのが簡単だからだと思う。あるいは、bunを始めるのを楽にするようなものだけど、長期的な価値はあまり加えないってこともある。例えば、コメントで誰かがsqliteモジュールとhttpサーバーについて話してたけど、今はNodeJSもsqliteをネイティブでサポートしてるし、ウェブ開発でサーバーを書くなら、ExpressやFastifyのような既存の、実績のあるフレームワークを使いたいな。クールなプロジェクトだし、V8を使わずに違うことに挑戦してるのはいいと思うけど、そんな漸進的な改善を売り込むのは難しいと思う。

これは新しい、VC資金で運営されているオープンソースの実績ある支配的プレイヤーへの競争相手だよね。ロックインするインセンティブがあって、結局ノードとあまり変わらない。bunを使うことに戦略的な利点はほとんどないし、ノードでできないことを実現するわけでもない。真剣に選んでる人はまだ見たことないけど、真剣じゃない人が使ってるのはよく見かける。

彼らのイシュートラッカーを見てみて。クラッシュがいっぱいで、どうやらこのZig言語はかなり危険みたい。俺はNodeに留まるよ。

BunもDenoも特に決定的な特徴はないよね。確かにNodeにも追加すべきいい機能はあるけど、エコシステムの変更や破損に対処するほどの魅力は感じないな。

俺はBunの一番のファンだよ。できるだけ毎プロジェクトで使ってるし、単発のスクリプトもBun/TSで書いてる。でも、プロダクション環境に導入するのはちょっと不安になる問題に遭遇したこともある。例えば、少し前にDocker内のExpressウェブサーバーがハングしちゃったことがあったけど、Nodeに切り替えたら問題なかった。1年前にはBun + Prismaのウェブサーバーがメモリリークしてクラッシュすることもあった。（もう1年経ったし、たぶんそれは修正されてると思う。）実際、Bunはすごく良くて、こういう面倒があっても時間を節約できると思う。トランスパイレーションやモジュール、ワークスペース周りの頭痛の種を解決してくれるのは本当に素晴らしい。でも、npmに近づいていない理由も理解できるよ。

既存のものを打ち負かすには、2倍良くならなきゃダメだよ。今のところ、合理的なサイズのプロジェクトに対しては1.1倍良くなってる進行中の状態で、進行中に期待される問題やエコシステムの信頼性が疑問視されてる。趣味のプロジェクトや小さな新規プロジェクトにはいいかもしれないけど、真剣な会社のプロジェクトをリスクにさらすつもりは全くないね。

BunとDenoを好きになりたいんだけど、何度か使ってみたけど、決定的な問題にぶつかるまでに数千行以上書いたことがないんだ。Bunで最後に大きな問題があったのはストリームが早く閉じちゃったことだね：https://github.com/oven-sh/bun/issues/16037 Denoでの最後の大きな問題はメモリリークだった：https://github.com/denoland/deno/issues/24674 今のところ、NodeエコシステムがBun/Denoの良い部分を取り入れる前に、Bun/Denoが本当に普及することはない気がする。

昨年試してみたけど、内蔵のsqliteドライバーと格闘するのに数時間かかったよ。バグも多くて（サイレントエラー）、ドキュメントも全然足りなかった。

まだいくつかの互換性の問題があるね… Denoにはかなり詳しくて、ここ数年ずっと使ってるから、今やデフォルトのシェルスクリプトツールになってる。でも、仕事のプロジェクトではMS-SQLにアクセスする必要があって、Denoのランタイムではソケット接続のやり方がサポートされてないんだよね。これが仕事でできることを制限してる。Bunでも他のモジュールやツールに似たような問題があると思う。エントロピーから抜け出すのもすごく難しいし。Node+npmは10年以上かけてそのエコシステムを築いてきたから、みんな簡単には手放せないよね。シェルスクリプトにはDenoが好きで、シェバンを使ったり、依存関係を参照したりすると、ランタイムがそれを処理してくれるから楽なんだ。「npm install」って別に実行する必要もないし、~/bin/ディレクトリが潜在的に競合するnode_modulesで汚れることもない。共有の（設定可能な）場所から使えるからね。Bunも似たような感じだと思う。ただ、仕事ではすでにあるシステムを使わなきゃいけないから、気まぐれで技術を置き換えるわけにはいかないんだよね。

私にとっての理由はこうだと思う：npm、pnpm、yarnはJSで書かれているから、libuvに基づくNode.jsの機能を使わざるを得ない。これはこの場合最適ではない。bunはZigで書かれているから、libuvが必要なくて、自分のことができる。もちろん、誰かがNode.jsのパッケージマネージャーをC/C++でネイティブモジュールとして書くこともできるけど、npm、pnpm、yarnはそうしなかったんだよね。

問題はlibuvがCだからじゃなくて、それを呼び出すのがJavaScript（Node.js）だから、libuvがシステムコールをするたびにモードを切り替えなきゃいけないってことじゃない？

Denoがベンチマークに含まれてないのは、思ったより比較が難しいからだと思う。Denoの依存関係のアーキテクチャはnpmを中心に作られてないし、その互換性レイヤーはコアの上に後付けされてるんだ（ソースコードを見ればわかるよ）。Denoの依存関係管理のコアアーキテクチャは、URLベースの異なるパラダイムを使ってる。速さはあんまりだけど…違うんだよね。それに、セキュリティが向上したり、自分の安全なレジストリを簡単にホストできるようなクールな機能もある。npmやjsrを使う必要はないし、すごく面白いけど、ここでベンチマークされてるものとは違うんだ。

ほんとに！リディアは複雑なアイデアをシンプルに、しかも上手に伝えるのが得意だよね。彼女の作品や動画はほとんど見たり読んだりしたけど、すごく手間をかけて生き生きとした内容にしてるのがわかる。彼女の記事やYouTube動画はほんとにおすすめ！ただ、今の仕事のせいであんまり書いてないみたいだけど。

ゼグで書かれてるなんて知らなかった！この言語がまだ若いのに、そんな選択をするのが面白いね。実際にプロダクションで使われてるのを見るのはすごいことだよ。

なんでpnpmをやめたの？

それを何千もの同時接続がそれぞれ複数のI/O操作を行ってると考えてみて。サーバーはI/O操作を待ってる時間が約95%だって。いや、特定の実行スレッドはI/Oを待ってる時間が95%だったかもしれないけど、サーバー（何千もの接続を提供してるマシン）はCPUの利用率が簡単に70%-80%で動いてるよ（それ以上になると、遅延がひどくなってくるから）。もしサーバーがフルロードでCPU利用率が5%だったら、十分な並列プロセスを動かしてないか、そうするためのRAMを十分にインストールしてないってことだよ。まあ、これは技術的なことだけど、投稿は技術的なことに専念してるから、こういう小さなミスが他の部分への信頼を損なうんだよね。（僕は文のファンとして言ってるんだけど。）