Cruller: BunのZigランタイム、Zig 0.16で継続

Cruller: BunのZigランタイム、Zig 0.16で継続 Showcase llm-deps, llm solenopsys 2026年7月16日 8:01 1 Cruller: Zig 0.16に移植された本番環境重視のBunランタイム Crullerは、ZigベースのBunの最終リリースからフォークし、既にビルドされた本番環境JavaScriptサーバーを実行するために必要な部分に絞り込み、バニラZig 0.16に移植したものです。リポジトリ: GitHub - solenopsys/cruller: fork of Bun · GitHub このプロジェクトは、JavaScriptCore、Bun.serve、HTTP/1-3、WebSockets、fetch、streams、Blob、Request/Response、静的サーバー、およびプリビルドJavaScript用のモジュールリゾルバを維持しています。パッケージマネージャー、バンドラー/トランスパイラー、シェル、テストランナー、ほとんどのCLIディスパッチ、N-API、SQLクライアント、アーカイブサポート、その他の開発指向のサブシステムは削除されています。 移植の興味深い部分は、ランタイムをBunの古いパッチ付きZigビルド統合から分離することでした。Crullerは現在、バニラZig 0.16のビルドグラフ、Zig 0.15以降変更されたAPI用の互換性シム、およびリリースビルドが実行時にビルドディレクトリから生成されたJSをロードするのではなくポータブルであるための生成コード埋め込みモジュールを備えています。 主な設計上の決定は、これを汎用的なBunの代替ではなく、ランタイムとして扱うことです。最小限のランチャーがプリビルドのエントリポイントをロードします。パッケージのインストール、バンドル、TypeScript変換、またはbun testを必要とする機能は意図的にスコープ外です。 現在、Linux x64での測定値は、公式Bun 1.3.14バイナリと比較して以下の通りです: Cruller Release Fast stripped runtime: 73.0 MiB Official Bun runtime: 88.5 MiB サイズ削減: 約18% V8 Crypto pure-JSベンチマーク: パフォーマンス同等; Crullerの中央値は2%高く、通常の実行間変動の範囲内です。 ランタイムはまだ開発中ですが、Zigのセマンティックチェック、リリースビルド、CJS/ESMエントリポイント、Nodeパステスト、およびHTTP Bun.serveと組み込みfetch()の簡単なテストは現在パスしています。 サポートされているZigバージョン Zig 0.16.0 Linux x64が現在サポートされているビルドターゲットです。 推奨トピックタグ: showcase, zig-0-16, llm AI / LLM使用状況の開示 AIは、Zig 0.16移行の一部、ビルド/デバッグ調査、および集中的なテスト作業のエンジニアリングアシスタントとして使用されました。プロジェクトのスコープ、アーキテクチャの決定、変更のレビュー、およびビルド/テスト検証は、引き続きメンテナーの指示に従います。これは純粋にAI生成されたプロジェクトではありません。 20 Likes xsawyerx 2026年7月16日 8:08 2 コードに対する批判に対処することを目指していますか？つまり、悪い設計上の決定などを削除することです。 4 Likes solenopsys 2026年7月16日 8:19 3 システムを可能な限り剥ぎ取り、本番に必要なものだけを残すのが私の考えです。開発はフルBunランタイムを使用して行われ、本番環境は軽量フォークであるCrullerを使用します。私はOvenチームのようなリソースを持っていないため、大規模な汎用ランタイムを開発・保守することはできません。そのため、特定のプロダクション要件に集中したいと考えています。主な目標は以下の通りです: HTTP/2およびHTTP/3サポートの強化。 ネイティブZMQプラグインの追加。 複雑なメモリ管理ポリシーと構成を可能にする、QuickJSベースの制御プレーンを介した動的メモリコントローラーの実装。 エンジンをシンプルな動的ライブラリとして、クリーンな.zigインターフェースでパッケージ化し、最小限の労力で他のアプリケーションに埋め込めるようにします。 Crullerは開発のためにBunを置き換えることを意図していません。これは、本番コードを実行するための最小限の、特殊化されたランタイムです。いずれにせよ、数年かかって構築されたこの巨大なコードベースを捨てたくはありません。Zigエコシステム全体で使用できる、便利な埋め込み可能なライブラリに変える方が理にかなっています。 15 Likes WeeBull 2026年7月16日 19:12 4 誰かがこれをやるだろうと思っていました。正直、幸運を祈ります。もしこのプロジェクトを真剣に続けるなら、学んだことについてコミュニティが興味を持つことは間違いないでしょう。私も同じ時点（最後のZigリリース）からbunのリポジトリを調べ始めましたが、スリム化するというあなたの考えは完全に正しいと思います。プロジェクトから約29万行のZigを削除したように見えます（71.2万行から42.5万行へ）。ビルドをzig buildの状態にするだけでも、大きなマイルストーンになりそうです。私は現在、以下で失敗しています… zig 0.16.0 build --build-file build016.zig check anyzig: build file 'build016.zig' anyzig: appdata '/home/pauls/.local/share/anyzig' anyzig: zig '0.16.0' already exists at '/home/pauls/.cache/zig/p/N-V-__8AAFFSVRWqblwBIcA-Yqv-u7sbjsJoww8K0mWaHbmJ' check └─ compile obj bzrt-check Debug native 1 errors error: failed to check cache: 'build/codegen/ZigGeneratedClasses.zig' file_hash FileNotFound error: 1 compilation errors 2 Likes shimekukuri 2026年7月16日 19:51 5 これがどこへ向かうのか非常に興味があります。DXの観点から、Zigの能力と設計思想により合致するパフォーマンスへと移行するのです。より大きなZigコミュニティから、これに取り組むことについての意見を聞くのは興味深いでしょうが、特にBun.serveやここにある他のものサポートに関しては、少し注意が必要です。 kristoff 2026年7月16日 20:37 6 それはかなりクレイジーな挑戦ですね、頑張ってください。このBunというもの全体について、私が特に不満に思っていることの一つは、Zigのコンパイル速度がどのように誤解されているかということです。このプロジェクトが、増分コンパイルを利用するために必要な作業を行い、Bunが最初から即時リビルドを楽しめたことを世界に示すことができれば、それは素晴らしいでしょう。 17 Likes solenopsys 2017年7月17日 2:13 7 ありがとう、あなたはクリーンチェックアウトのブートストラップバグを見つけました。build016.zigはbuild/codegenから生成されたモジュールをインポートしていましたが、それらのファイルはgitによって無視されています。修正してプッシュしました: zig build --build-file build016.zig check はまずコード生成ターゲットを実行し、次にZigセマンティックチェックを実行します。まだブートストラップのためにインストールされたBunが必要ですが、残りのジェネレーターはTypeScriptです。コード生成をZigネイティブにすることは別のマイルストーンです。削減は意図的です: Bunは開発ツールチェーンのままで、Crullerはパッケージマネージャー、TypeScriptトランスパイラー、バンドラー、シェル、またはテストランナーを持たずに、プリビルドされたJavaScriptを実行するためのものです。 3 Likes skdishansachin 2017年7月17日 3:49 8 まず、幸運を祈ります！私が考えていたことの一つは、メモリの問題はJSCとZigの相性が悪いこと（GC対手動メモリ）から来ているのであって、Zig自体が悪いわけではないということです。Rustもそれを解決するわけではありません（私はまだあまり調査していませんが、間違っているかもしれません）。Rustでも数千のunsafeブロックがあり、それらの同じ問題が発生しています。なぜなら、Rustの型システムは、それが所有していないガベージコレクタを推論できないからです。したがって、言語の変更はランタイム自身のコードのバグに役立ちますが、JSC/Zigの問題の根本的な問題を本当に解決するわけではありません…Crullerではこの問題にどのように対処するつもりですか？QuickJSベースのメモリコントローラーについて言及しましたが、それはこれに関連していますか？ 2 Likes solenopsys 2017年7月17日 6:00 9 最初は、Rustへの移行はClaudeがAIの「強力さ」を誇示するためのマーケティング的な見せかけに過ぎないと思っていました。実際には深刻な障害にぶつかったようです。移行は数日で終わるはずでしたが、3ヶ月経ってもリリースされていません。実際には「数千」ではなく13,000ものunsafeブロックがあります。そのため、この変更はあまり実質的な利益をもたらさなかったようです。もしClaudeが主張するほど強力なら、なぜJSC自体をRustに切り替えるのではなくZigに移行しないのでしょうか？それは能力の真のデモンストレーションになったでしょう。さらに、Rustのメモリ保護メカニズムと同様のものをZig内でビジネスロジックに選択的に実装することもできたはずです。私が構築を計画しているメモリコントローラーについてですが、それはロケット科学ではありません。ランタイムがアイドル時に200〜300MBを消費しないようにJSCのパラメータを管理したいだけです。現時点では、主要なエンジン変更に深く入り込むことはないと思います。現在の目標は、ビジネスロジックとReactベースのSSRの両方で安定して動作させることです。パフォーマンスとメモリ最適化は…