HN 日本語サマリー

← 一覧へ戻る
プログラミング

Bun 1.4 Rust書き換えは芳しくない

Bun 1.4 Rust rewrite is not looking good (tipiirai.com)

71 pointsby tipiirai42 コメント

要約

Bun 1.4のRustへの書き換えプロジェクトは、度重なるリリース延期とAIによるコード生成への過度な依存により、コミュニティの不満を高めています。当初のZigでの開発から方針転換し、AI主導で進められたRustへの書き換えは、多くの未解決のプルリクエストやコードの品質に関する懸念を生んでおり、当初の目的であったメモリ安全性さえも疑問視されています。

全文翻訳

Bun 1.4 Rust書き換えは芳しくない 私はBunを気にかけています。2022年の最初のリリース以来、ずっと応援してきました。NodeからBunにすべての開発を切り替えました。Nueフレームワークの開発で使い、今は新しいプロジェクトHerttaでも使っています。 過去3ヶ月間、Bunにとって良い兆候は見られませんでした。それは、私がこれまで見た中で最も印象的な個人のエンジニアリングプロジェクトの一つとして始まりましたが、今では継続的な虚偽の約束とますます不満を募らせるコミュニティを持つ、奇妙なAI駆動の生き物へと変貌してしまいました。 次のバージョンのBun かつて「次のバージョンのBun」という言葉は、機能が実装され、テストされ、数日中にリリースされることを意味する、ポジティブなツイートでした。しかし、Rustへの書き換えの後、それは変わりました。今では、今後のリリースに関する虚偽の約束の投稿になっています。 Jun 24 Bun v1.4は7月7日にリリースされます。 Jul 4 Bun v1.4、おそらく火曜日 Jul 7 (日付が過ぎる) Jul 14 次バージョンのBunで Jul 20 次バージョンのBunで Jul 29 Bun v1.4はv1.3から3000以上の問題を修正 Aug 1 次バージョンのBunで Aug 4 次バージョンのBunで Aug 7 あと1つのPRをマージすればBun v1.4の時間です Aug 13 Bun v1.4はコンパイル中です。 Aug 15 Bun v1.4は月曜日に延期 Aug 17 明日としましょう 安定リリースから3ヶ月以上が経過し、Bunの歴史上2022年以来最長のギャップとなっています。ソフトウェアの遅延は普通のことです。ただ、かつては実際の日付と数字でコミュニケーションを取っていたアカウントが、「バイブス」に変わってしまったのです。そして、ユーザーの反応は、度重なる虚偽の約束の後に予想されるものです。 @jarredsumner OK、ブログ記事を編集しています。ほぼ完成しました。日付を言っても信じないでしょうが、明日としましょう。 私たちはあなたを完全に信じています、Jarred。 喜べ、みんな、明日はJarred標準時で、来週新しいブログが来るぞ。 あなたは気にしないでしょうが、個人的には今Goに切り替えます。 面白くもない、あなたはユーザーを何度も何度も引き延ばしているだけです。どうすればあなたを信じられるでしょうか?あなたはいつも約束を守れない約束をします、明日、来週、月曜日… リリースに2ヶ月かかるなら、毎週「明日リリースする」と言う代わりに、そう言えばいいのに。 GitHub上のBun Bun 1.4の書き換えは、AIへの大きな賭けです。過去1ヶ月で、15.8kのコミットがrobobunから、1.6kのコミットがautofix-ci[bot]から、790のコミットがJarredから来ています。6ヶ月前、BunのPRのほとんどは、人々がClaudeにプロンプトを入力したものでした。最近では、BunのPRのほとんどは、ClaudeがClaudeにプロンプトを入力したものです。 プロジェクトには5,000以上のオープンなプルリクエストがあり、これは私がこれまで見た中で最も多い数です。比較すると、OpenClawは2.2k、Reactは441です。GitHubは、マージ可能性チェックがタイムアウトし始める前に、単一ブランチに対するオープンPRを1,000未満に保つことを推奨しています。 最大の懸念は、もちろんコードそのものです。初期の頃、Jarredの仕事は刺激的でした。私は彼が真のZigの才能だと思っていました。しかし、Zigの作者Andrew KelleyがBunの書き換えについて述べたことを読むまでは。 「Bunのコードベースで見られるプログラミングプラクティスに、私たちはますますぞっとしました。ハックの上にハック。アサーションの乱用。Jarredは、LLMにアクセスするずっと前から、すでにずさんなコードを書いていました。」 Zigに何が問題だったのでしょうか? この書き換えは、AIエージェントが人間の指示をほとんど読まずに、本番コードベースを引き継ぐことができるかどうかを検証する、最も注目されている実世界でのテストです。Anthropic自身の評判もかかっています。これがうまくいけば、エージェントコーディングが何ができるかの真の証拠となります。もしうまくいかなければ、逆のシグナルを送ることになるでしょう。 Rustコード内のunsafeブロックの数は、書き換えが当初の理由であったメモリ安全性を実現できなかったことを示唆しています。むしろ、この書き換えはAnthropicの広告のように感じられます。そして、Zigが本当に問題だったのでしょうか?Bunの初期のアイデンティティはZigの上に築かれていました。そのパフォーマンス、高速なコンパイル時間、低摩擦、少人数のチームによる直接的なメモリ制御です。JarredとAnthropicは早い段階で、これがRustで書かれるべきだと決め、Zigのメモリ問題を、Claudeがいかに強力であるかを世界に知らせるための口実として使ったように思われます。このような書き換えは大きな見出しを作り、実際にそうしました。今、私たちは書き換えによる、彼らが準備していなかった長期的な問題に直面しています。おそらくBunは、そのAI支援の努力を、人間が理解できる規律あるZigに注ぐべきだったのでしょう。言語全体を変更するのではなく。 私はJarredがこの選択肢を真剣に検討しているのを見たことがありません。そして「明日」は来て、過ぎ去りました。まだv1.4はありません。¯\_(ツ)_/¯