世界を動かす技術を、日本語で。
bun upgrade --canaryコマンド実行「ただの実験だから、みんな大げさに反応しすぎだよ」っていうのは、批判を抑えるための嘘だったみたいだね。
「まだ書き直すとは決めてない。全てのコードが完全に捨てられる可能性も高い。」
あの時は実験だったみたいで、うまくいったのかな？でも、2.xでリリースしてくれるといいな。1M LoCがこんなにいろんな方法で壊れるなんて想像できないよ。特に、xiphiasが言ってることが本当ならね。
9日で別の言語で完全に書き直すのは狂気の沙汰だと思う。もしかしたら俺が慎重すぎるだけかもしれないけど、こういうのは別のバイナリとして分けて、まずは重いユーザーをテスターとして巻き込んで、予期しない問題が出ないか確認してから徐々に広げていくべきだと思う。元のコードベースをこの新しいものに切り替える前に、リグレッションが起きない自信を持ちたいな。
実験がうまくいったかもしれないし、著者が自分が安心できるところまで持っていくのに十分な時間をかけたのかもしれない。フラストレーションが山を動かすって言うし、この書き直しは軽い気持ちでやったとは思えないな。
信じてないけど…9日後…行くぞおおおおおおおおおお！
9日前のことだったから、その時は自信がなかったけど、結果がめちゃくちゃ良かったのかもね。
いや、恥ずかしい思いしてるわ。あの投稿でbunを擁護してたんだ。みんなが過剰反応してると思ってた。特に、心配してたことが馬鹿げてたから。誰がそんなクレイジーなことするんだ？当時は「プロジェクトが数ヶ月で切り替わるなんてありえない」って本気で思ってた。仮にそんなことがあったとしても、数日で実現するなんて想像もできなかった。今は本当に混乱してる。
あのコメントから、実験がメインにマージされない可能性が0%だと言ってる部分はある？「このコードが完全に捨てられる可能性が非常に高い」とは見たけど、それはつまり捨てられない可能性が低いってことだよね。
アンスロピックがこれを推進したのは、実験が注目を集めたからかもね。うまくいけば、マーケティングの良い事例になるだろうし。
それが嘘かどうかなんて分からないよ。俺はよく、クランカー艦隊に数日間、捨てるつもりのクソみたいなものを作業させるけど、結果的にすごく良くなることもあるから、そのまま残してる。あのコメントが投稿された時、彼はうまくいくとは思ってなかった可能性も十分あるよ。（LLMコードのデフォルトとしては妥当だけど、時々はうまくいくこともあるしね。）
自動翻訳の実験をする人がいるのは実際ワクワクするけど、互換性の問題がたくさん出てきそうで心配だな。コミットを見始めたけど、基本的には「テストが通らない」問題をテスト自体を変えることで解決しようとしてる感じ。すでにデプロイされているプログラムで動かすための本当の作業は、これから始まるってことだね。唯一の救いは、サーバーサイドのJSコミュニティは、なぜか常に壊れることに慣れてるってことかな。
コミットを見始めたけど、基本的には「テストが通らない」問題をテスト自体を変えることで解決しようとしてる。これらの決定がLLMによってなされたかは分からないけど、Claudeは問題の正しい解決策を見つけるよりも、テストを変更するような「怪しいこと」をする傾向があると思ってた。GPT/Codexはこの点ではもっと正直だね。
すぐに安定版リリースになるとは思わないけど、間違ってたら嬉しいな。このリライト全体にはちょっと懐疑的で、Jarred Sumnerはすごいフォロワーがいるから、広告みたいに感じる。
コミットを見始めたけど、基本的に「テストが通らない」問題をテスト自体を変えることで解決してる。すでにデプロイされているプログラムで動かすための本当の作業は、今から始まるところだね。うわ、これは確かにすごいことだ。Jarredはコミットを読んだかどうかコメントしてくれたり、君のコメントに返事してくれたりするかな？もしこれが正しいなら、bunがやってることに対する小さな信頼を失っちゃった。
テスト自体を変えることで「テストが通らない」問題を解決してる https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed... これ最高！テストにランダムにsleep(1)を追加するだけで大丈夫、心配しないで、うまくいくから！
自分のRUNTIMEに誰も見たことのないコードが含まれてるっていう考えはちょっと不安だけど、もしこれが問題なく動くならかなりすごいことだよね。
tszでは100%のテストが通ってるのに、バグがめっちゃある。実際、世の中のソフトウェアが完全にテストされてるとは思えない。俺もこのアイデアを試してるところなんだ。今のところ、たくさんのことを学んだよ。コードを書く未来は、かなりLLMに助けられると思ってる。
もしこれが少しでも失敗したら、自分の供給品でハイになってる麻薬ディーラーの嘲笑が永遠に続くことになるだろうね。
ちょっとでもうまくいかないことに対して、感情的に準備できてる人が少ない気がする。
PRがめっちゃ厚くて、最初に開いたときにページが読み込まれなかったし、コメントもまだ読み込めない。マジで面白い。最近のGitHubは普通じゃないから、どうかは分からないけど。1,009,257行追加、4,024行削除、6,755コミット、2,188ファイルに触れた。これをレビューしようと思う人がいるなんて、全く理解できない。もっとAIを使うのかな？それとも、超ハードコアなリンティングをかけるとか？コードレビューというより、リスクアセスメントの練習みたいだね。
こんな大きさのポートをレビューする意味があるのかは疑問だな。Jarredによると、unsafeが1000以上使われてて、Zigのコードと同じパターンを使ってるらしい。TypeScriptチームがTypeScriptからGoにコーディングモッドでポートしてるのと似たような感じがする。
もう人間はbunを維持してないよ。これを理解してるって主張するのは無理があると思う。
データセンターの天才たちは、自分たちのフォークを維持・改善するのではなく、別の言語でコードベースを丸ごとリライトすることを選んだんだね。1MLOCを1週間でリライトするのはすごいけど、これはデータセンターに詰め込まれた百万匹の猿プログラマーの仕事みたいだ。僕は猿プログラマーだから、今危険にさらされてる…もしかしたらZigチームの方がもっと危険かも。彼らの頭には、クランカーたちが欠けてる天才のエッセンスが詰まってるから、2027年までには持ってるべきだね。
これをどう見ても、単なる無駄な作業にしか見えないよ。翻訳が無料で理想的なRustの表現になっても（実際はそうじゃないし、今はRustの構文を使ったZigになってるけど）、結局は無駄な作業なんだよね。プロジェクトの規模が大きくなると、言語自体はあまり制約にならなくて、むしろ過去のアーキテクチャの決定を乗り越えたり、大きな変更を統合したり、深い最適化をしたり、コードベースをプロジェクトのロードマップや長期目標に合わせたり、機能が追加されるたびに回帰テストをしたり、複数のリリーストレインのメンテナンスをしたりすることが重要になってくる。経験豊富なソフトウェアエンジニアは、その時点でプログラミング言語の選択みたいな単純なことにはあまり気にしなくなるんだよね。なぜなら、その選択からくる問題はすでに解決されているから。大事なのは安定性、大きな変更の慎重な調整、そして安定して包括的なテストスイートだよ。
現在の言語をより良くするために貢献すること Zigを作っている人たちは、そうしたくないって言ってたよ。
テスト自体が修正されてるのを見るのが好きで、いくつかにランダムなsleep(1)が入ってるのがいいね。これは良い兆しだ。どこかの大手AI企業のバカが、実際にこのゴミをプロダクションで使っちゃうことを祈ってる。
Claude CodeはBunをランタイムとして使ってるよ。これがマージされたなら、Bun-rustはAnthropicの内部エージェントがライブテストを行うのに十分な性能を持ってると思う。
これについてのブログ記事を書いてるところ。もっと詳しい情報を共有するよ。どこから来てるかは、Bun v1.3.14以前のリリースノートのバグ修正をざっと見てみて。Rustではこれらをすべてキャッチできないから、参照を長く保持しすぎたり、JSの境界を越えて再入するものはまだこちらの問題なんだ。でも、そのリストの大部分はuse-after-free、double-free、エラーパスでの解放忘れで、これらはコンパイルエラーや自動クリーンアップになるんだ。
bunをウェブサーバーとして使う際に、ほとんどメモリの問題が起きないことを願ってる。
ブログ記事楽しみにしてるよ。ZigとRustのバイナリを並行して、幅広い実際のアプリケーションで（実際のプロダクションで影響を与えながら）バグを取り除く予定はある？
これが有料顧客にどれくらいのコストがかかるのか、ちょっと興味あるな。見積もりを教えてもらえる？
Bun Workers APIの安定性の問題は、これで解決しそうですか？ https://bun.com/docs/runtime/workers
2つのバイナリを比較するようなe2e（ファジー？）テストを実施したり、する予定はありますか？リリースに関して特別な計画はありますか？（例えば、ユーザーのワークフローを壊さないようにするとか）
つまり、これからはBunのコードベースで作業しているコーディングエージェントも、そのrust-Bunランタイム上で動いているってこと？
9日前のあなた[0]: > 私はBunで働いていて、これが私のブランチです > このスレッド全体は過剰反応だ。動かないコードについて302件のコメント。再書き込みを約束したわけじゃない。すべてのコードが完全に捨てられる可能性が非常に高い。もしかして…そんなに過剰反応じゃなかったのかも？ [0]: https://news.ycombinator.com/item?id=48019226
最新のBunリリースで修正されたこのHTTPリクエストスムグリング攻撃ベクターに対して、CVEを発行する予定はありますか？
Bunを使っているいくつかのプロジェクトを他のものに移行するつもり。こんな無謀な変更を許すガバナンスは信用できない。
同じく、やっぱりノードに留まるつもり。逆に、火の試練はどうなるか楽しみだね…長期的には、きっと問題は解決されると思う。
一方で、3年以上前にZigから移ったのは正しかったなって思う。Rustに全部移行したけど、Zigは不安定で危険すぎると思ってたから。コンパイル時の愛着はあるけど、BunやTigerbeetleが言われるように言語のせいじゃないって意見もあったし。でも、Zigプロジェクトがフラッグシッププロジェクトを失うのは可哀想だなとも思う。プロジェクトが時代遅れだと思っても、自分の心血を注いだものが一週間で置き換えられるのは、遠くから見てもショックだよね。数年前は、レガシーコードやリライトが遅すぎて、こんなことは考えられなかった。Tigerbeetleも、顧客の信頼を得るための他のプロジェクトがなくなった今、解決策を主張するのが難しくなるんじゃないかな。マーケティングの圧力で、最終的に彼らも同じ道を辿るかもしれないし（Zigコンパイラにやられた後、彼らがその上に超高信頼性のデータベースを載せるとは思わなかったけど、他の大手が使ってるから、企業の顧客には少し安心感があったのかも）。
Zigのメンテナーたちは、Bunからの巨大なPRを恋しがることはないだろうね！
新しいポートのコードコメントの多くは、どうやってポートされたかの議論だけに関するもので、元のZig実装を参照していることが多い。だから、今は何が起こっているのかを理解するために、実質的に2倍のコメントとコードを読まなきゃいけない感じだよ。