5 ポイント 投稿者 GN⁺ 2025-11-17 | 2件のコメント | WhatsAppで共有
  • Rustでゼロから実装されたJavaScriptエンジンで、ECMAScript仕様をほぼ完全にサポートする構成
  • 現在 ECMAScript言語の97%以上を通過しており、test262ベースのテストで検証済み
  • V8のIgnition設計とSerenityOSのLibJSに着想を得て、ほとんどの構成要素を 依存関係を最小限に抑える 方針で直接実装
  • バイトコードVMコンパクティングGCカスタムRegExpエンジンパーサーを含み、仕様準拠の組み込みオブジェクトと関数を提供
  • まだ 本番用途としては未完成 だが、ES2025レベルの機能を備えたRustベースJSエンジン開発における重要な前進

Brimstone概要

  • Brimstoneは Rustで完全に新規実装されたJavaScriptエンジン で、ECMAScript仕様を忠実に実装することを目指している
  • 現在 ECMAScript言語の97%以上をサポートし、test262テストを通過
  • まだ本番環境で使う準備はできていない 開発進行中のプロジェクト である

設計と実装

  • ECMAScript仕様を直接実装し、V8SerenityOSのLibJS から設計上の着想を得ている
  • エンジンの大部分の構成要素を 依存なしで自前実装 しており、例外的に ICU4X のみを使用
  • 主な構成要素:
    • V8 Ignition を参考にした バイトコードベースのVM
    • 非常にunsafeなRustコードで書かれたコンパクティングGC
    • カスタムRegExpエンジンパーサー
    • 仕様に準拠した 組み込みオブジェクトおよび関数の実装

ビルドと実行

  • 標準の Cargoコマンド でビルドと実行が可能
    • cargo buildbs 実行ファイルを生成
    • cargo run でソースから直接実行
  • JavaScriptファイルの実行例:
    cargo build
    ./target/debug/bs ./hello.js
    Hello world!
    

テスト体制

  • 公式 test262 を含むファーストパーティおよびサードパーティの統合テストセットを活用
  • カスタム統合テストランナー を同梱(cargo brimstone-test コマンドで実行)
  • 単体テストおよびスナップショットテストは cargo test で実行
  • 追加のテスト情報は tests/README.md で確認可能

未実装機能

  • ES2024までのすべての機能2025年2月のTC39会議時点のStage 4提案 の大半を実装
  • まだ未対応の機能:
    • SharedArrayBuffer
    • Atomics

2件のコメント

 
shakespeares 2025-11-19

すごいですね..

 
GN⁺ 2025-11-17
Hacker Newsのコメント
  • 作者です。このプロジェクトが紹介されていて本当にうれしいです。
    @ivankra が javascript-zoo に追加してベンチマークを回してくれたおかげで、感謝しています。
    この3年間、完成度と性能を高めるために着実に時間を注いできた趣味プロジェクトです。
  • 簡単に比較すると、リリースビルド基準で Boa は 23MB、Brimstone は 6.3MB ほどです。
    Boa レベルの機能を満たして本番向けに強化すればサイズは大きくなるかもしれませんが、この小ささで 仕様の97%を通過しているのはかなり印象的です。
    • Boa は内部に Unicode テーブル を含んでいます。
      Brimstone はそうではないので、それがサイズ差の大半を占めています。
      Unicode 処理をきちんと行うには数MBのデータが必要なので、最近は小さな実行ファイルを作るのが簡単ではありません。
      Unicode サポートが必須なら、最小サイズには限界が出ます。
    • 何かサイズ最適化を別途適用したのか気になります。
      デフォルト設定は通常 性能重視 なので、codegen-units=1 や panic 削減のようなオプションを変えると結果が変わるかもしれません。
    • 最後の数パーセントを埋める過程で、サイズが不均衡に増えることもあります。
      Boa は約91%しか通過していないので、Brimstone のほうが完成度は高いです。
      小規模プロジェクトほどコードが 小さくきれいで保守しやすい ものです。
      協業には常に一定の オーバーヘッド が伴います。
  • Boa と比較してもらえるとありがたいです。
    Boa リポジトリ
    • こちらのベンチマーク結果 を見ると、1人プロジェクトとしては驚くほど完成度が高いです。
      機能は Boa とほぼ同じで、一部のベンチマークでは 速度が2倍 です。
  • なぜ Rust で書かれたプロジェクトはいつも「Rust で書かれている」と強調するのか気になります。
    • 昔は「Lisp で書かれている」「Ruby で書かれている」「JavaScript で書かれている」といった時代もありました。
      自然な流れだと思います。
    • Rust は(unsafe がなければ)特定の バグのクラスを根本的に防げる という点で意味があります。
      ただ、このプロジェクトは unsafe をかなり多く使っているそうです。
    • Rust エコシステムに投資している人にとって、新しいプロジェクトを 見つけるシグナル になるからです。
    • Rust は悪くない言語ですが、JS/TS から移ってきた若い開発者が過剰に信奉する傾向があります。
      一種の Blub 現象 のようなものです。
    • Rust はメモリアロケーションと型を明示的に扱う必要があるため開発難易度は高いですが、そのぶん 品質の高いソフトウェア が多いです。
      結局はマーケティング要素でもありますが、平均して完成度が高いのは事実です。
  • 「Compacting garbage collector, written in very unsafe Rust」という文言がすごく面白かったです。
    • 話題とは違いますが、昔の cracktro イントロ が懐かしいです。
      OS の起動前に Ikari のイントロが出るのを想像してしまいました。
  • 既存の JS エンジンと比べるとどうなのか気になります。
    • javascript-zoo のベンチマーク を見ると、おおまかな比較ができます。
    • このエンジンは Rust プログラムに 直接埋め込めます
      C/C++ のリンクなしで完全な Rust ネイティブ です。
      40MB の単一バイナリサーバーに JS スクリプティングを追加できます。
      Rust ベースの JS エンジンがいくつも出てきたのは本当に素晴らしいことです。
  • Rust の最大の利点の1つが メモリ安全性 なのに、なぜわざわざ unsafe な GC を使ったのか疑問です。
    • Rust には高性能な GC がないので、unsafe で 新しいメモリ管理体系 を実装するのは合理的です。
      unsafe な領域を最小限に抑えれば問題ないと思います。
    • 実際、Vec のような標準ライブラリですら内部的には unsafe を使っています。
      重要なのは unsafe を 小さな領域に限定 して検証可能にすることです。
      GC 実装はその例外的な領域です。
    • Rust の unsafe であっても、C++ のように undefined behavior の範囲が広いわけではありません。
      私が JS ランタイムを Rust で作るとしても、まず安全に実装して必要なときだけ unsafe を使うでしょう。
    • unsafe はコンパイラが理解できない部分を 開発者が直接制御 するための道具です。
      高性能 GC を実装するには、どうしても必要になる部分です。
    • 個人的には、Rust の メモリ安全性の強調は誇張気味 だと感じます。
      Rust は単に速くて良い命令型言語です。
  • ライセンスが見当たりません。
    • ミスでした。今は MIT ライセンス で公開しています。
    • 基本的には、大企業による 搾取的な利用を許さない 方向を歓迎する立場です。
  • 「Rust はガベージコレクション言語ではない」という点を誤解しているコメントがありました。
    • Rust は GC 言語ではなくRcArc を使うときだけ参照カウントが適用されます。