Buz : BunのZigによるモダンなフォークで、1秒未満で再構築

Bunへの移行後、ZigコミュニティのメンバーがBuzを発表。Buzは、最新のZigで書き直されたBunのフォークで、サブセカンドのインクリメンタルビルドを約束。Hacker Newsで224ポイントを獲得。

具体的な事例

Bun（Nodeの並列JavaScriptランタイム）は主にZigで書かれています。Zigは「Cがやることを、より良くやる」という約束で魅力的なシステム言語です。しかし、Bunが成長するにつれ、比較的古いバージョンのZigに固定され、ファイルを1つ変更するだけでコンパイル時間が爆発的に増加するようになりました。

そこで、Buzが登場します。これは、2026年7月24日にZigの公式フォーラムであるziggit.devでコミュニティメンバーによって発表されたフォークです。そのコンセプトは1行で要約できます：「最新のZigを使用したBunのドロップイン置換え、増分ビルドが1秒未満」。Hacker Newsでは、この発表は224ポイントと161コメントに達し、新しいプロジェクトとしては大きなシグナルとなりました。

これは、Bunエコシステムにとって重要な時期に起こっています。先週、Simon WillisonはClaude CodeがBun（Rustコア）を使用していることを文書化しました。これは、BunがAIツールチェーンに組み込まれつつあることを示しています。したがって、貢献の速度に関する摩擦は、単にプロジェクトだけでなく、より広範囲な課題となります。

理解すべきこと

プロジェクトの名前、Buz（「Bun」＋「Zig」）は、単なる言葉遊びではありません。これは技術的な賭けを文書化しています：

• Zigの最新バージョンに追随する（言語は1.0のプレリリース段階で、breaking changesは頻繁ですが、コンパイラの最適化は迅速に進化しています）。
• Zigの自ホスト型コンパイラを活用し、真に意味のある増分ビルドを実現する。
• BunとAPI互換性を保ち、エコシステムを分断させない（Deno vs Nodeのように）。

核心は、サブセカンドの増分ビルドです。このような大きなランタイムにハックをする際、各「1行変更→テスト」サイクルは重要です。数十秒から1秒未満に短縮されることで、貢献のエルゴノミクスが完全に変わります。これは、プロジェクトが外部の開発者を引き付けるか、創設チームに固定されるかを決定するような細部です。

真の議論

HNのコメントは2つの陣営に分かれています：

1. 熱心な支持者 - コミュニティ主導のフォークは、Jarred Sumner（Bunの創設者）が時間を割くことができなかったことを解放する可能性があります。注目すべき前例は、OpenSSL/LibreSSLのフォークや、io.jsがNode.jsに圧力をかけたことです。
2. 懐疑論者 - 発散のリスクは現実的です。「ドロップイン置換え」が5%のAPIを逃すと、結局問題を解決するよりも多くの問題を引き起こす可能性があります。Bunのような大きなプロジェクトのフォークを維持するには、多くの人手が必要です。

私たちの解釈

これは、Bunの真の競合相手としてよりも概念実証としてより興味深いでしょう。Buzがこの規模のコードベースでサブセカンドのビルドが可能であることを示すことができれば、Bunチームは最適化をアップストリームに戻すことができ、それが全員にとって利益になるでしょう。「フォークがオリジナルを動かす」というパターンは、オープンソースの常です。

注目すべきは、今後数週間のコミット頻度です。15日後に消えるフォークはよくありますが、3ヶ月続くフォークは数えられるほどです。

覚えておくべきこと BuzはまだBunの信頼できる代替品ではありませんが、Bunが使用するZigのバージョンの停滞がプロジェクトの速度を遅らせているという真の問題を指摘しています。Buzが成功するかどうかは別として、機械的な効果はBunに対してより速く移行するように強制することになります。これはまた、Bunの新しいAIツールチェーンでのポジショニング（Claude Code）との関係も示しています。