Buz – モダンZigを採用し、1秒未満のインクリメンタルビルドを実現したBunのフォーク

Buz – モダンZigを採用し、1秒未満のインクリメンタルビルドを実現したBunのフォーク Buzこれは私のWIP（作業中）のBunフォークで、Rustへの書き換え前の最後のコミットに基づいています。開発はまだ非常に初期段階であり、本番環境での使用には全く対応していません。 Ziggitで類似のプロジェクトがすでに投稿されているのを見かけましたが、開発の重複を避けるために私のプロジェクトも投稿します。ただし、現時点では他のプロジェクトは見ていません。 Bunを現在のアップストリームZigでビルドできるように移植しました（インクリメンタルリビルドを機能させるためのマイナーパッチを適用）。ビルドグラフ全体がbuild.zigにあり、JavaScriptCoreのベンダーソースも含まれています。これにより、1秒未満のインクリメンタルビルドが可能になり、プロジェクトの開発ループが大幅に改善されます。 目標は、より健全なコードベースを持つBunのドロップインリプレイスメントになることです。そのために、Rust版Bunの新しいテストをすべてプロジェクトにインポートしました。これらのテストの多くは、新機能やバグ修正をカバーしています。まだ多くのテストがパスしていませんが、これはアップストリームに追従する継続的な作業になります。 しかし、その過程でコードベースの「スロップ」（無駄なコード）を削減し、技術的負債を減らすよう努めています。そのために、Bunから完全にデッドコードとなっていた11,000行以上を削除しました。これほど neglect されたコードベースで11K行ものデッドコードに達するプロジェクトは他にないと思います。 また、コードベースの一部を書き直し、近代化しました。Zigの標準ライブラリへの依存度を高めることを試みています。その過程で、数え切れないほどのバグも修正されました。 サポートされているZigバージョン プロジェクトは、わずかにパッチが適用されたZigマスターサブモジュールを使用しています。これは主にインクリメンタルビルドに関するものです。昨日のコミット2b1c663のアップストリームZigであれば、問題なくビルドできるはずです。 AI / LLM 使用に関する開示 Bunは、現時点では典型的なAIスロッププロジェクトです。それを引き継ぐのは容易ではありません。60万行ものスロップコードのこの混乱を解きほぐすために、人間の正気を犠牲にすべきだとは思いません。そのため、プロジェクトが十分に健全だと判断されるまで、人間がコーディングした貢献は受け付けません。おそらく、ほとんどのサブシステムを書き直す必要があるでしょう。 この目的のために、LLMが広範囲に使用されます。しかし、うまくいけば、人間が主導し、技術的負債の削減とidiomaticなZigの記述に焦点を当てた、より良い開発プラクティスにより、数週間または数ヶ月後には、Rust版Bun 1.4.0のドロップインリプレイスメントとして機能する、提示可能なコードベースが存在するでしょう。 SolまたはFableにアクセスできる場合は、私をより速くそこへ到達させるのを手伝ってもらえます。Bunのコードベースで最もひどいスロップのケースがあれば、遠慮なく指摘してください。私はそれらを修正し、近代化するために最善を尽くします。私はこれを自身のZigスキルを向上させるための方法として使用しています。長期的には、LLMの助けなしにメンテナンスするのが快適なコードベースになることを願っています。 8 Likes kracked July 24, 2026, 6:29am 2 素晴らしい計画ですね。FableやSolは持っていませんが、応援したいです。 1 Like Ray-D-Song July 24, 2026, 6:53am 3 私もJavaScript Runtimeをビルドしましたが、正直なところ、ZigやRustがBunの最もコアな部分だとは思いません。Bunを構成しているのは、JSC、uWebSockets、brotli、lol-html、tinyccなどのC/C++プロジェクトです。ZigやRustは単なる接着剤にすぎません。だからこそ、JarredがBunをRustで書き直すことにもあまり興味がありませんでした。接着剤を書き直すのはあまり意味がなく、同様に、Zigフォークを維持し続けることもあまり意味がないのです。 したがって、これらの依存関係をZigで書き直す計画があるかどうか、またJavaScriptCore用のv8互換APIを実装する計画があるかどうか、興味があります。Bunのパフォーマンスはすでに優れている（コードの品質に関わらず、そのパフォーマンスはNodeやDenoを本当に凌駕しています）ので、問題は安定性とV8/N-APIの互換性だけです。コミュニティはこれらの問題に対処するプロジェクトを歓迎するでしょう。 3 Likes jazzzooo July 24, 2026, 7:32am 4 フィードバックありがとうございます！Bunが単なる接着剤であれば、クリーンアップは簡単だったでしょう。接着剤はたくさんありますが、そのほとんどは実際のコードです。約3/4を占めていると言えるでしょう。例えば、パッケージマネージャーは4万行のコードです。そしてもちろん、すべてのNode APIとWeb APIはZigで実装されています。それが提供する10〜20の他のネイティブ機能は言うまでもありません。 現在の機能セットを維持し、新しいBunの機能やJSCのアップデートに追従するだけでも、非常に大変でしょう。プロジェクトが安定したら、いくつかの小さな依存関係を書き直すことは構いませんが、Brotliのような大規模で確立されたプロジェクトと競争することになるとは思いません。少なくとも、これがサイドプロジェクトである間は。 ZigはBrotliをビルドするのに十分な能力があります。Bunにはすでにいくつかのv8互換性があります。そのコードを見ずに済んだことを嬉しく思います。私の理解では、人気のあるパッケージを動作させるための部分的なV8 APIシムがありますが、完全なカバレッジには程遠いです。したがって、より良い解決策が現れない限り、これは今後も戦略となるでしょう。 安定性についてですが、Jarredがうまくできなかった点や、私が改善できる点について、何か具体的なことはありますか？ kristoff July 24, 2026, 9:40am 5 これはソフトウェアの「改修」という点で本当に興味深いプロジェクトのようです。そして、オリジナルのメンテナーにとって私にとって最大の機会損失だったこと、つまり高速なインクリメンタルビルドを実現できたことを、あなたが達成できたことを非常に嬉しく思います。 もしあなたのプロジェクトにもっと注目を集めたいのであれば、インクリメンタルリビルド速度をデモするブログ記事を書くことをお勧めします。インクリメンタルビルドがほぼ完全なアーキテクチャ/OSサポートに近づくにつれて、私たち（zsf）もそれについてもっと宣伝するつもりです。デモビデオも含めて。 2 Likes