- Buzは、BunがRustで書き直される直前のコミットを起点に、最新のZigベースの互換代替を目指して開発中の初期段階のフォーク
- JavaScriptCoreのベンダー同梱ソースまで含むビルドグラフ全体を
build.zigへ移し、Zigに小規模なパッチを適用して1秒未満のインクリメンタルビルドを実現 - Rust版Bunの新機能・バグ修正テストを取り込んだが、失敗するテストが多く、アップストリーム機能とJavaScriptCoreの変更を継続的に追いかける必要がある
- 未使用コードを11,000行以上削除し、一部実装をZig標準ライブラリ中心にモダナイズする過程で複数のバグも修正
- まだ本番環境では使えず、LLMと人間の監督を併用して技術的負債を減らしたうえで、長期的にはLLMなしでも保守しやすいコードベースを作ることが目標
プロジェクトの目標と開発状況
- Buzは、BunがRustで書き直される前の最後のコミットをベースにした開発中のフォーク
- Bunと互換性のある代替でありつつ、従来より整理されたコードベースを作ることに重点を置く
- 開発は非常に初期段階で、本番環境で使う準備はできていない
- 類似のZigベースBunプロジェクトがすでにZiggitで公開されている状況で、開発作業の重複を避けるためにBuzを公開
- 公開時点では、そのプロジェクトはまだ検討していなかった
最新Zigへの移植とインクリメンタルビルド
- Bunを現在のアップストリームZigへ移植し、インクリメンタルリビルドのためにZigへ小規模なパッチを適用
- JavaScriptCoreのベンダー同梱ソースを含むビルドグラフ全体を
build.zigに統合 - この構成によりインクリメンタルビルド時間が1秒未満に短縮され、開発の反復サイクルが高速化
- プロジェクトには、インクリメンタルビルド用パッチを適用したZig
masterサブモジュールが含まれる - 当時のアップストリームZigコミット
2b1c663でも正常にビルド可能
互換性テストとアップストリーム追跡
- Rust版Bunに追加されたテストを取り込んでおり、新機能とバグ修正を検証するテストも多数含まれる
- まだ通過しないテストが多く、Bunのアップストリームに継続して追いつく必要がある
- 機能互換性を維持しながらコードを整理し、技術的負債を減らす作業も並行
- JavaScriptCoreの変更も継続的に追跡する必要がある
コードベースの整理とモダナイズ
- Bunでまったく使われていないコードを11,000行以上削除
- 一部コードを書き直し・モダナイズしながら、Zig標準ライブラリの活用を拡大
- 整理とモダナイズの過程で複数のバグも同時に修正
- 既存のBunコードベースは約60万行規模で、整理された状態に到達するには多数のサブシステムを書き直す必要があると見ている
LLMの活用とコントリビューション方針
- 複雑な既存コードを整理するためにLLMを広範に活用しつつ、人間による監督とより良い開発プラクティスも併用する計画
- コードベースが十分に整理されたと判断するまでは、人間が直接書いたコントリビューションは受け付けない方針
- 技術的負債の削減と慣用的なZigコードの記述を優先し、数週間または数か月以内にRust版Bun 1.4.0の互換代替として出せるコードベースを目標とする
- SolまたはFableを使える開発者の支援を求めている
- 長期的には、LLMの助けがなくても保守しやすいコードベースを作り、開発過程でZigのスキルも高めようとしている
1件のコメント
Hacker News の反応
まだ Zig のインクリメンタルコンパイルは aarch64 をサポートしておらず、バイナリパッチも Linux リンカーでしか可能ではないが、主要プラットフォーム対応は時間の問題に見える
1人チームで1秒ビルドを達成したという事実は、遅いビルドが不注意な開発慣行の結果であり、フォークに時間を費やしたのは完全に誤ったリソース配分だったことを示している
結局、もっと多く、あるいはもっと上手に指示するという意味に見える。コード構造は好みの領域でもある気がするが、昨日は HTTP リクエスト1件を処理するのにバックエンドプロセスが4つ必要だと主張する友人と、呆れるような会話をした
人間が介入する時代は、最初から暫定段階だったのだと思う
大規模プロジェクトではよくあることなのに、自分が知らなかっただけなのか気になる
if (false) { dead_code(); }のように明白なコードなのか、動的ディスパッチは可能だが論理上呼ばれ得ないコードなのかは不明。前者なら1.8%は高いが、後者なら低いかもしれない。古い機能フラグの裏に、事実上永遠に実行されないコードが積み上がっているプロジェクトも多い単純なユーティリティや生成コードのような少量の死んだコードは残してもよいが、削除が連鎖的な削除や単純化につながることもある
厳密には死んだコードではなかったが、小さな誤った抽象化を一つ整理すると次の整理機会が次々に開け、最終的には意図したことだけをするソフトウェアが残る。コードベースは時間とともに肥大化するので、Bun 規模で11,000行しか見つからなかったことのほうがむしろ驚き
チック段階では機能を素早く追加して、正確だが極度に散らかったバージョンを作り、タック段階では成果物を消化して整理し、性能・保守性・変更への脆弱性を改善する
1日かけてバイブコーディングで動くアプリを作った後、カードの家のように崩れずに機能を追加し続けられるプロジェクトにするために1週間を使うことがよくある。AI 以前にも似たことはあったが、プロの開発者はシステムに対するメンタルモデルがより強く、作業速度も遅かったので、切り替わりはここまで急激ではなかった
コーディングモデルはカプセル化を破る近道を選んだり、重複してはいけないコードを複製したりする傾向が強い
大きなプロジェクトでは、テスト実行や意味エラー確認のたびに何分も待つことはできないので、ビルド時間は明確なボトルネックだ
AI を強く支持しているからというより、コンセプチュアルアートや実験として、2つのプロジェクトがどう異なる進化をするのか見ると面白そうだ
リンク: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
HN 議論: https://news.ycombinator.com/item?id=49017344
https://nubjs.com
目的別ツールを組み合わせるのも問題ではないが、デフォルト状態であらゆる問題が解決されているほうが非常に便利。Bun バンドラーにはランタイム API もあり、アセットを提供する同じプロセスが外部バンドラーと調整したり静的ファイルをディスクに書いたりせず、メモリ上でそのままバンドルできる