Brimstone – Eine in Rust geschriebene ES2025-JavaScript-Engine

• Eine von Grund auf in Rust implementierte JavaScript-Engine, die die ECMAScript-Spezifikation nahezu vollständig unterstützt
• Besteht derzeit mehr als 97 % der ECMAScript-Sprache und ist durch test262-basierte Tests verifiziert
• Von V8s Ignition-Design und SerenityOS' LibJS inspiriert, wobei die meisten Komponenten mit minimalen Abhängigkeiten selbst implementiert wurden
• Enthält eine Bytecode-VM, einen komprimierenden Garbage Collector, eine eigene RegExp-Engine und einen Parser sowie spezifikationskonforme eingebaute Objekte und Funktionen
• Noch nicht produktionsreif, aber ein wichtiger Fortschritt bei der Entwicklung einer Rust-basierten JS-Engine mit Funktionsumfang auf ES2025-Niveau

---

Überblick über Brimstone

• Brimstone ist eine vollständig neu in Rust geschriebene JavaScript-Engine mit dem Ziel, die ECMAScript-Spezifikation originalgetreu umzusetzen
• Unterstützt derzeit mehr als 97 % der ECMAScript-Sprache und besteht die test262-Tests
• Es handelt sich noch um ein laufendes Projekt, das noch nicht für den Einsatz in Produktionsumgebungen bereit ist

Design und Implementierung

• Implementiert die ECMAScript-Spezifikation direkt und ist konzeptionell von V8 und SerenityOS' LibJS inspiriert
• Die meisten Komponenten der Engine sind ohne Abhängigkeiten selbst implementiert, mit ICU4X als einziger Ausnahme
• Zentrale Bestandteile:
  • Eine Bytecode-basierte VM nach dem Vorbild von V8 Ignition
  • Ein komprimierender Garbage Collector, geschrieben in sehr viel unsafe Rust-Code
  • Eine eigene RegExp-Engine und ein Parser
  • Spezifikationskonforme eingebaute Objekte und Funktionen

Build und Ausführung

• Build und Ausführung sind mit den standardmäßigen Cargo-Befehlen möglich
  • cargo build erzeugt die ausführbare Datei bs
  • cargo run startet direkt aus dem Quellcode
• Beispiel zum Ausführen einer JavaScript-Datei:

  cargo build
  ./target/debug/bs ./hello.js
  Hello world!
  

Testsystem

• Nutzt ein Integrations-Testset aus offiziellen test262-Tests sowie Tests von Erst- und Drittanbietern
• Enthält einen eigenen Integrations-Test-Runner (ausführbar mit dem Befehl cargo brimstone-test)
• Unit- und Snapshot-Tests werden mit cargo test ausgeführt
• Weitere Testinformationen finden sich in tests/README.md

Noch nicht implementierte Funktionen

• Alle Features bis ES2024 sowie die meisten Stage-4-Vorschläge nach dem Stand der TC39-Sitzung im Februar 2025 sind implementiert
• Noch nicht unterstützte Funktionen:
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Krass ..

[GN⁺]

Hacker-News-Kommentare

• Ich bin der Autor. Es freut mich wirklich sehr, dass dieses Projekt hier vorgestellt wurde
  Vielen Dank an @ivankra dafür, dass er es zu javascript-zoo hinzugefügt und Benchmarks laufen lassen hat
  In den letzten drei Jahren war das ein Hobbyprojekt, in das ich kontinuierlich Zeit investiert habe, um Reifegrad und Performance zu steigern
• Zum einfachen Vergleich: Im Release-Build ist Boa etwa 23 MB groß, Brimstone ungefähr 6,3 MB
  Wenn es den Funktionsumfang von Boa erreicht und für den Produktionseinsatz gehärtet wird, könnte es größer werden, aber mit dieser kleinen Größe 97 % der Spezifikation zu bestehen ist ziemlich beeindruckend
  • Boa enthält intern Unicode-Tabellen
    Brimstone tut das nicht, und das macht den Großteil des Größenunterschieds aus
    Für eine saubere Unicode-Verarbeitung werden mehrere MB an Daten benötigt, daher ist es heutzutage nicht einfach, kleine Executables zu bauen
    Wenn Unicode-Unterstützung Pflicht ist, gibt es eine Mindestgröße, unter die man kaum kommt
  • Ich frage mich, ob gesonderte Größenoptimierungen angewendet wurden
    Die Standardeinstellungen sind normalerweise eher auf Performance ausgelegt, daher könnten Optionen wie codegen-units=1 oder das Entfernen von Panics das Ergebnis verändern
  • Beim Füllen der letzten paar Prozent kann die Größe unverhältnismäßig stark anwachsen
    Boa besteht nur etwa 91 %, also ist Brimstone vollständiger
    Gerade bei kleineren Projekten ist der Code oft klein, sauber und leicht wartbar
    Zusammenarbeit bringt immer einen gewissen Overhead mit sich
• Ich würde gern einen Vergleich mit Boa sehen
  Boa-Repository
  • Die Benchmark-Ergebnisse hier zeigen, dass das für ein Ein-Personen-Projekt erstaunlich ausgereift ist
    Der Funktionsumfang ist Boa fast ebenbürtig, und in einigen Benchmarks ist es doppelt so schnell
• Ich frage mich, warum bei in Rust geschriebenen Projekten immer betont wird, dass sie „in Rust geschrieben“ sind
  • Früher gab es auch Zeiten mit „in Lisp geschrieben“, „in Ruby geschrieben“ oder „in JavaScript geschrieben“
    Ich halte das für einen natürlichen Verlauf
  • Rust ist insofern bedeutsam, als es — sofern kein unsafe verwendet wird — bestimmte Bug-Klassen von vornherein ausschließt
    Allerdings soll dieses Projekt ziemlich viel unsafe einsetzen
  • Für Menschen, die in das Rust-Ökosystem investiert sind, ist das ein Signal zum Entdecken neuer Projekte
  • Rust ist eine ordentliche Sprache, aber junge Entwickler, die aus JS/TS kommen, neigen dazu, sie übermäßig zu verehren
    Das wirkt wie eine Art Blub-Phänomen
  • Rust verlangt, dass man Speicherallokation und Typen explizit behandelt, was die Entwicklung schwieriger macht, aber dafür gibt es viele hochwertige Softwareprojekte
    Letztlich ist es auch Marketing, aber im Durchschnitt ist der Reifegrad tatsächlich höher
• Die Formulierung „Compacting garbage collector, written in very unsafe Rust“ fand ich extrem lustig
  • Hat zwar nichts mit dem Thema zu tun, aber ich vermisse die alten cracktro-Intros
    Ich stelle mir vor, wie vor dem OS-Boot ein Ikari-Intro erscheint
• Ich frage mich, wie es im Vergleich zu bestehenden JS-Engines aussieht
  • Die Benchmarks von javascript-zoo ermöglichen einen groben Vergleich
  • Diese Engine lässt sich direkt in Rust-Programme einbetten
    Komplett Rust-nativ, ohne C/C++-Linking
    Man kann einem 40-MB-Single-Binary-Server JS-Scripting hinzufügen
    Es ist wirklich großartig, dass es inzwischen mehrere Rust-basierte JS-Engines gibt
• Einer der größten Vorteile von Rust ist doch Speichersicherheit — warum also absichtlich einen unsafe-GC verwenden?
  • Da es in Rust keinen Hochleistungs-GC gibt, ist es vernünftig, mit unsafe ein neues Speicherverwaltungssystem zu implementieren
    Solange der unsafe-Bereich klein gehalten wird, halte ich das für in Ordnung
  • Tatsächlich verwendet selbst die Standardbibliothek intern unsafe, etwa bei Vec
    Wichtig ist, unsafe auf kleine Bereiche zu begrenzen, damit sie überprüfbar bleiben
    Die Implementierung eines GC ist so ein Ausnahmebereich
  • Selbst Rust-unsafe hat nicht so einen breiten Bereich an undefined behavior wie C++
    Wenn ich selbst eine JS-Runtime in Rust bauen würde, würde ich sie zuerst sicher implementieren und nur bei Bedarf unsafe einsetzen
  • unsafe ist ein Werkzeug, mit dem der Entwickler direkt die Kontrolle über Teile übernimmt, die der Compiler nicht verstehen kann
    Für die Implementierung eines Hochleistungs-GC ist das stellenweise unvermeidlich
  • Persönlich finde ich, dass die Betonung der Speichersicherheit bei Rust übertrieben ist
    Rust ist einfach eine schnelle und gute imperative Sprache
• Ich sehe keine Lizenz
  • Das war ein Versehen. Inzwischen steht es unter der MIT-Lizenz
  • Grundsätzlich begrüße ich eher eine Richtung, die ausbeuterische Nutzung durch Großkonzerne nicht erlaubt
• Es gab Kommentare, die missverstanden haben, dass „Rust keine Garbage-Collection-Sprache ist“
  • Rust ist keine GC-Sprache; Referenzzählung kommt nur zum Einsatz, wenn man Rc oder Arc verwendet