Brimstone: ES2025 JavaScript engine written in Rust

Original Article ↗ Hacker News Discussion ↗

Comparisons to Other JavaScript Engines

  • Brimstone is seen as impressively compliant for a one-person project, close to Boa in features but generally faster in shared benchmarks, sometimes about 2× Boa’s speed.
  • Binary size comparison (release builds): Boa ~23 MB vs Brimstone ~6.3 MB, with people noting this is notable given Brimstone passes ~97% of the spec.
  • Hermes and QuickJS are highlighted as strong contenders in the broader benchmark suite, balancing performance and binary size.
  • Samsung’s Escargot draws curiosity due to high ES2016+ compliance and small size, but is viewed as:
    • Too slow vs V8 (3% on one benchmark set) for general use.
    • Filling a niche for Samsung TVs/appliances or non‑JIT environments; Hermes is seen as a better alternative for that niche.
    • More spec-compliant than Hermes, which some consider important when JITs or V8 are not allowed.

Binary Size, Unicode, and Intl

  • Major size gap with Boa is largely attributed to Unicode/ICU data:
    • Boa embeds large ICU tables and ECMA‑402 Intl/Temporal data.
    • Brimstone embeds a smaller, language‑minimal Unicode set.
  • Discussion notes Unicode’s inherent bulk (collation, locales, etc.), arguing that “correct” text handling has a real size floor.
  • Others feel ICU packs in rarely used locale/calendaring details and should be optional or system-provided, not bundled into every interpreter.

Rust, Unsafe, and Garbage Collection

  • Some are puzzled by explicitly “very unsafe Rust” for the compacting GC, given Rust’s memory-safety reputation.
  • Multiple replies argue:
    • Implementing high-performance GCs and custom memory regimes almost inevitably needs unsafe.
    • The Rust model is to confine unsafe to small, auditable layers and expose safe APIs.
    • Even core types like Vec use unsafe internally; zero unsafe is unrealistic.
  • There’s side discussion about atomics and memory fences, with the view that Rust’s standard atomics often suffice without inline assembly.

Rust Ecosystem, Syntax, and Dependencies

  • Mixed views on Rust:
    • Proponents praise its error-handling model, safety, and code quality.
    • Critics complain about syntax complexity, heavy dependency trees, and slow compile times, comparing Rust culture to npm-like bloat.
  • Some distinguish the Rust language from its OSS culture, noting you can write low‑dep Rust, but community norms favor many “battle‑hardened” crates.

“Written in Rust” and Use Cases

  • Several comments ask why “written in Rust” is always foregrounded.
  • Defenders say:
    • For libraries, language matters because it determines ease of integration (e.g., pure Rust dependency vs C/C++).
    • “Written in Rust” signals likely memory safety (if little unsafe), speed, better average quality, and easier multi-platform binaries.
  • Others see it as hype or a generational fad, similar to earlier “written in Lisp/Ruby/JS” eras.

Embedding and Practical Value

  • A key benefit noted: Brimstone can be embedded in Rust programs without C/C++ linking.
  • This enables small Rust servers or apps to be scriptable in JavaScript with a purely Rust toolchain, which several commenters find “awesome.”

Licensing and Project Status

  • Initial lack of a license raises concerns; this is later corrected to MIT.
  • The author notes it started as a hobby project and has evolved over three years, focused on completeness and performance.

Miscellaneous

  • Some lighthearted remarks about the executable name and “compacting GC, written in very unsafe Rust” line.
  • Brief nostalgic tangent about cracktros and boot-time intros.