Bunサポートが制限され、非推奨予定へ移行
(github.com/yt-dlp)- このイシューはまだ Open 状態であり、次回の yt-dlp および/または
ejsリリースから、Bun のサポート範囲を1.2.11以上1.3.14以下に制限し、サポート自体も非推奨予定へ移行する - yt-dlp は Bun を
ejs互換の JavaScript ランタイムとして引き続き使用するが、保守負担が大きくなれば Bun サポートを完全に削除する権利を留保する - 最低サポートバージョンは従来の
1.0.31から1.2.11に引き上げられる。1.2.0より前の Bun でejsパッケージをビルドするとejsのロックファイルが無視され、最近の npm サプライチェーン攻撃を踏まえると重大なセキュリティ懸念になると見られている - 下限を
1.2.0ではなく1.2.11とした理由は、1.2.11より前の Bun ではejsテストスイートを実行できないため - 上限は
1.3.14に設定されており、このバージョンが元の Zig コードベースでビルドされた最後のリリースであることが根拠として示されている - Bun は最近 Claude を使って Rust に書き直され、開発方針も「完全に vibe-coded」な方向に見えることから、今後の保守負担と信頼性の問題が懸念されている
- あるコメントでは Deno も「vibe coded」されていると反論されたが、管理者は Claude を使うこと と Claude に完全に依存すること の間には大きな違いがあると回答した
1.3.4から1.3.14までについても、Anthropic による買収後の「vibe coding」の影響を受けている可能性があるのでサポート対象から外すべきではないかという質問に対し、管理者は検討すると答えた- 一部のユーザーは、実際の問題が発生する前から最新の Bun 実行を止めるのは根拠のない先制的な制限であり、警告やフラグを設けたうえで引き続き実行できるようにすべきだと反対している
- 別のコメントでは、
--js-runtimesに Bun バイナリのパスを直接渡せるため、最新の Bun は通常どおり使いつつ、yt-dlp 専用に静的な Bun1.3.14を指定する回避策が可能だと説明している - 関連告知として、Node v20・v21 のサポート終了イシューと、Deno の最低サポートバージョンを
v2.3.0に引き上げるイシューがあわせてリンクされており、EJS のWiki文書 はまだ今回の変更を反映していないと案内されている - 管理者は Hacker News から流入したコメントを意識し、コメントする前に本当に yt-dlp で Bun を使う問題に関心があるのかをまず考えてほしいという固定コメントを残している
1件のコメント
Hacker News のコメント
この判断は理解できる。保守担当者自身が書いていないコードが大半なら、コードベースをきちんと理解するのは難しいだろうと思う
全面書き換えのコードをレビューするのも、実質的には不可能だ。実際に100万行ものコードがある https://github.com/oven-sh/bun/pull/30412
結局は同じ内容を別の文法で書いたものに近く、そのため Rust 開発者の目には見栄えが悪く映るのだろう。Bun の開発者たちは、自分たちにとって馴染みのある見た目のコードを望んでいたように思える
ただ、これは2.0と呼ぶべきだったと思う。そうしていれば、ここまで急いでいる感じも薄れただろう。1.3.14 にもリグレッションがいくつかあるが、今は小さな Rust 関連の火事が多すぎて、誰もあまり気にしていない雰囲気だ
より大きな問題は、Bun がきらびやかな新機能を追い続けて最後まで仕上げないことだ。テストは Vitest の大半だが全部ではなく、Jest も大半だが全部ではなく、pnpm も大半だが全部ではない。今は画像機能まで入って、sharp の大半だが全部ではない。開発サーバーも Vite の大半だがやはり全部ではない。長時間動くプロセスは Node とおおむね似ているがメモリリークがあり、これが Rust 移行の動機だったのかもしれない
画像ルーチンの記事を見たときは気持ちが沈んだ。また別のきらびやかな対象だったし、テストのバグも重なって、結局は完全に Vitest に移行した
この書き換え自体が良いアイデアでうまくいくと確信しているわけではないが、それに反対する論理も同じくらい納得しにくい
その100万行超が何をしているのか誰もわからない。それを情熱を持って扱う人もいない。要求を受け取り、触らなければならない表面だけを除いて、残りは全部ブラックボックスとして扱う
その結果、同じことをするバックグラウンドサービス実装が14個、同じ役割の依存関係が8個、重複するフレームワークが6個、スタイルとアプローチの完全な不一致が生まれる。それでも大して重要視されない
純粋な「バイブコーディング」よりはましだと思うが、重要でない部分ならともかく、本当に深く考える必要がある中核インフラでは受け入れがたい
誰かの人種や宗教を差別しているわけでもない。大規模なバイブコーディングされた表層を望まないなら、わざわざ言い訳する必要があるのかと思う
これは開発者としての「芸術的」裁量の範囲であり、ソフトウェアには本質的に意見が入り込むという事実を忘れているように見える
動くならそのまま動き続けるはずだ。ただ、彼らはそれをサポートして保守し、issue を解決したくないだけだ
Rust に移植された Bun が、測定可能なあらゆる面でより優れていて、テストをすべて通し、性能が同等かそれ以上で、既存のバグも修正しているなら、どの言語で書かれ、どう実装されたかがなぜ重要なのかと思う。重要なのは品質がより高いことだ
Bun チームが Rust 版をリリースし承認したときに信用できないのなら、2週間前の Zig 版をなぜ信用していたのかも論理的に筋が通らない。yt-dlp 開発者たちは愚かに見える
Bun を使うのが本当に好きなので、Anthropic による買収後に方向性がこう変わるのは少し悲しい
バッテリー同梱型の良い Node を望んではいるが、それがバイブコーディングされたものであってほしいわけではない
マージを支持するという意味ではない。こういう YOLO 的なエンジニアリング手法には反対だ。ただ、発表以降の続報を見ていないので、移行がどう進んでいるのか知りたい
もちろん、ひどく悲しい意味で皮肉だということだが
この判断はエンジニアリングというより政治的判断に近く見える。Rust への書き換え後の Bun でセグメンテーションフォルト、メモリ不足、セキュリティ脆弱性、バグが増えたのを見たのか？
もちろん、まだその書き換え版は入ってもいないのだから見ているはずがない。AI が関わっていると考えるだけで気分が悪いから決めているように見える
エンジニアリングツールは気分ではなく、望む仕事をこなせるかどうかで選ぶ。Bun のバグが増えて、より悪いソフトウェアのように感じるなら使わないが、その判断はデータに基づく。Jarred は Bun で印象的な仕事をたくさんしてきたし、自分の品質基準を満たさない書き換え版を出す可能性は低そうなので、様子を見るつもりだ
セキュリティ脆弱性が増える合理的な可能性があると考えながら、ユーザー相手に実験するのはむしろ不注意だとすら言える
責任ある選択は、「今の main から切り出された新しい Bun リリースで自分たちのソフトウェアが動くことを直ちにサポートしない」に近い
ただ、今後のリリースを再評価する計画ではなく、今後も絶対にサポートしない意図のように見える点は残念だ。もちろん yt-dlp の開発者たちが誰かに借りがあるわけではないが
100万行の全面書き換えは、従来と同じ ABI を持つ事実上の新ランタイムであり、多くの下流利用者にとっては本番依存関係にするには気が進まない対象だ
議論のために言えば、Bun がすべて人手で書き直されていたとしても状況は同じだったはずだ。こういう判断はかなり標準的だと思うし、個人的には Bun の LLM 書き換え品質も全体として良いだろうとは思うが、自分の製品や会社を賭ける気にはならない。危険な変更は自分のソフトウェアで自分が選びたいのであって、下位依存関係のせいで押し付けられたくはない
バグが噴き出して全部壊れ始めるまで座って待つつもりはない
「ツールが望むことをするかどうかだけを見て選ぶ」といった考え方の人のプロジェクトなら、自分の依存関係から外すだろう
列車事故になりそうなツールから離れるのが最も簡単なのは、まだ統合する前だ
これは Rust 変換についての話だが、まだリリースはされていない
「予見可能な互換性およびセキュリティ問題」と言っているが、Zig 版の Bun もかなり頻繁にクラッシュする
yt-dlp がなぜ予見可能な互換性問題があるのか、詳しい根拠にリンクしてくれたらよかったのにと思う。両プロジェクトともテストスイートがあるのだから、理想的な世界なら高速な書き換えも可能なはずだ
状況をこれ以上刺激したくないだけかもしれないが、具体的に見つかった問題があるなら見てみたい
Bun.rs はマイナーリリースではなく、1.4 か 2.0にして、アルファ版やベータ版も出してほしかった
だが、公開されてからまだ1週間しか経っておらず、今のところ実際のリグレッションのデータはほとんど見当たらない。もっと「ただ気に入らない」という愚痴に近く見える
この理屈は、「libfoo が vim ではなく emacs で開発されるようになったから、もう信用できない」と言っているのと大差ないように読める
もちろん完全に同じではないが、似て感じられる理由はある
ソフトウェアで唯一の真実は、自分のユースケースで動くかどうかだ。AI 以前でも、作者が厳密に進めたのか、それとも動くまで手当たり次第に試していたのかはわからなかった
つまり、方法論や使ったツールを調べてソフトウェアを判断していたわけではない。テストスイートがないかボロボロのソフトウェアもたくさん使ってきたし、メモリ安全性が好きな人たちも C で書かれたツールを使うし、その逆も同じだ
だから、「AI の使い方が気に入らないから使わない」という理屈は、作者のエディタ選びが気に入らないから使うのをやめると言っているのと同じくらい説得力が弱く聞こえる
そうでなければ、フェアトレードのチョコレートやコーヒーのような概念は存在しなかったはずだ
製品を使う顧客にとっても、これは保守担当者がエディタを変えたのとほぼ同じで、無関係な細部だと言えるだろうか？
しかし、LLMについてまでそう言う人は多くないはずだ
バイブ Bun が以前の Bun と同じくらい良い、あるいはそれ以上かもしれないが、現時点でどうやってそれを知れるのか？
また、「ソフトウェアが厳密に作られたかどうかはわからず、方法論で判断しなかった」というのも事実ではない。採用前や継続利用を決める際に、許容できるレベルの厳密さがあるか自分で確認する人たちはいる。自分も重要な用途ではそうしている
もっと多くの人は評判というシグナルを使うが、それは完璧でなくても相関があり十分な場合が多く、直接の手動レビューよりはるかに簡単だ
開発作業での LLM 利用の仕方を説明する新しい用語が切実に必要だ。「バイブコーディング」には本来かなり厳密な定義があるのに、誰も気にしていない雰囲気がある
Rust への移植が、元の定義どおり100%「バイブ」だけで行われたと信じるのは本当に難しい
肯定にせよ否定にせよ感情が入り混じった泥仕合になっていて、「バイブコーディング」を一般的なLLM 利用の蔑称のように使うと、実際にどんな問題を指しているのか把握するのが難しくなりすぎる
自分は開発を補助するために LLM を使っており、エンジニアが重視しうるあらゆる測定基準で、より良い仕事をより速くこなしている
https://x.com/karpathy/status/1886192184808149383
この特定の移植については、進行が速すぎて、人間が翻訳の妥当性を検証していないことは明らかに見える。今後、手動検証が実際に行われるのかも不明だ
ただ、Dijkstra の基準で見れば、AI が登場するずっと前からほとんどのソフトウェアプロジェクトはすでに「バイブコーディング」していた。雰囲気に任せて、正確性が存在するという事実を忘れるという意味で
複雑なコードの正確性を保証するのは難しいが、いまやデータセンターの中にハッカー10億人がいる時代になりつつあり、ますます任意では済まなくなるだろう
追記: 「Bun の未リリース Rust ポートにはunsafe ブロックが13,365個ある」
https://news.ycombinator.com/item?id=48239790
まだ新しい技術すぎて研究も難しいが、楽観的に見ても実証的な証拠は一部領域で約3%の改善程度しか示していない
コードを書くことが我々の仕事のボトルネックであることはまれだ
この判断にこれほど圧迫感を覚える人が多いのはなぜなのかわからない。本物のバイブコーディング愛好家なら、より良い yt-dlp を自分でバイブコーディングするか、既存のものをフォークして必要な形にすればいいのではないか？
しかも、人々はあらゆる作業のために使い捨ての個人用ソフトウェアをバイブコーディングするようになる、とまで言われていた
それなら、バイブコーダーたちはどんなソフトウェア上の判断にも文句を言う理由がないはずだ。もっと気に入る個人フォークをバイブコーディングするのは朝飯前であるべきではないか？ それがバイブコーディングの約束だったのではないか？
これは、自分以外の人の時間と労力で維持されているプロジェクトに対して人々がしばしば抱く、誤った権利意識だ。自分の欲しい機能のために、他人の時間と労力を当然のようにボランティア提供させようとする態度には、今でも驚かされる
実際に作業している人たちには決定を下す権利があり、気に入らなければ自分でフォークすればいい。このエコシステムは最初からそうだった
yt-dlp は今でも驚くほど手を入れやすい部類だ
職場でもそういう状況を経験しているが、AI に関しては正直な技術的異論が許されないのが本当にうんざりする
Bun の書き換えについてどう感じればいいのかわからない
一方では、コードベースの大半がレビューされていないという点が非常に恐ろしく感じられる
他方では、聞くところではほとんどリグレッションなくテストを通しているという
そのあたりの経験が足りないだけかもしれないが、自分はテストをそこまで信頼して、コードを読まずに全面的に依存することはないと思う