Brimstone - Un moteur JavaScript ES2025 écrit en Rust

• Moteur JavaScript implémenté entièrement en Rust à partir de zéro, avec une architecture visant une prise en charge presque complète de la spécification ECMAScript
• Passe actuellement plus de 97 % du langage ECMAScript, avec une validation basée sur les tests test262
• Inspiré par la conception d’Ignition de V8 et par LibJS de SerenityOS, avec la plupart des composants implémentés en interne avec un minimum de dépendances
• Inclut une VM à bytecode, un ramasse-miettes compactant, un moteur RegExp personnalisé et un parseur, ainsi que des objets et fonctions intégrés conformes à la spécification
• Encore inachevé pour un usage en production, mais représente une avancée importante dans le développement d’un moteur JS en Rust avec des fonctionnalités de niveau ES2025

---

Présentation de Brimstone

• Brimstone est un moteur JavaScript entièrement réécrit en Rust, dont l’objectif est d’implémenter fidèlement la spécification ECMAScript
• Il prend actuellement en charge plus de 97 % du langage ECMAScript et réussit les tests test262
• Il s’agit encore d’un projet en cours de développement, pas encore prêt pour un usage en production

Conception et implémentation

• Il implémente directement la spécification ECMAScript et s’inspire, sur le plan de la conception, de V8 et de LibJS de SerenityOS
• La plupart des composants du moteur sont implémentés maison sans dépendances, à l’exception de ICU4X
• Principaux composants :
  • VM à bytecode inspirée de V8 Ignition
  • Ramasse-miettes compactant écrit en Rust très unsafe
  • Moteur RegExp personnalisé et parseur
  • Implémentation des objets et fonctions intégrés conforme à la spécification

Compilation et exécution

• Compilation et exécution possibles avec les commandes Cargo standard
  • cargo build génère l’exécutable bs
  • cargo run exécute directement depuis les sources
• Exemple d’exécution d’un fichier JavaScript :

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

Système de test

• Utilise un ensemble de tests d’intégration de première et troisième parties, incluant le test officiel test262
• Comprend un runner de tests d’intégration personnalisé (exécutable avec la commande cargo brimstone-test)
• Les tests unitaires et les tests snapshot s’exécutent avec cargo test
• Des informations supplémentaires sur les tests sont disponibles dans tests/README.md

Fonctionnalités non implémentées

• Implémente toutes les fonctionnalités jusqu’à ES2024 ainsi que la plupart des propositions Stage 4 selon la réunion TC39 de février 2025
• Fonctionnalités encore non prises en charge :
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Incroyable...

[GN⁺]

Commentaires Hacker News

• Je suis l’auteur. Ça me fait vraiment plaisir de voir ce projet présenté
  Merci à @ivankra de l’avoir ajouté à javascript-zoo et d’avoir lancé des benchmarks
  C’était un projet hobby sur lequel j’ai investi du temps régulièrement ces trois dernières années pour améliorer la maturité et les performances
• Pour une comparaison simple, en build de release, Boa fait 23 Mo et Brimstone environ 6,3 Mo
  Il est possible que la taille augmente s’il atteint le niveau de fonctionnalités de Boa et est renforcé pour la production, mais réussir à passer 97 % de la spec avec une taille aussi réduite reste assez impressionnant
  • Boa inclut en interne des tables Unicode
    Brimstone ne le fait pas, et cela représente l’essentiel de l’écart de taille
    Gérer correctement Unicode nécessite plusieurs Mo de données, donc produire de petits exécutables n’est plus si simple aujourd’hui
    Si la prise en charge d’Unicode est indispensable, il existe une limite minimale de taille
  • Je me demande si des optimisations de taille spécifiques ont été appliquées
    La configuration par défaut vise généralement les performances, donc modifier des options comme codegen-units=1 ou supprimer les paniques pourrait changer le résultat
  • Les derniers pourcents peuvent faire grossir la taille de façon disproportionnée
    Boa ne passe qu’environ 91 %, donc Brimstone est plus abouti
    Plus un projet est petit, plus le code est petit, propre et facile à maintenir
    La collaboration implique toujours un certain overhead
• Je me demande si on peut le comparer à Boa
  Dépôt Boa
  • Les résultats de benchmark ici montrent un niveau de maturité étonnamment élevé pour un projet mené par une seule personne
    Les fonctionnalités sont presque équivalentes à celles de Boa et, sur certains benchmarks, il est deux fois plus rapide
• Je me demande pourquoi les projets écrits en Rust insistent toujours sur le fait qu’ils sont « écrits en Rust »
  • Il y a déjà eu des époques où l’on mettait en avant « écrit en Lisp », « écrit en Ruby » ou « écrit en JavaScript »
    Je trouve que c’est une évolution naturelle
  • Rust a un intérêt réel dans la mesure où, s’il n’y a pas d’unsafe, certaines classes de bugs sont bloquées à la source
    Cela dit, ce projet utiliserait pas mal d’unsafe
  • Pour les gens qui ont investi dans l’écosystème Rust, c’est un signal pour découvrir de nouveaux projets
  • Rust est un bon langage, mais les jeunes développeurs venus de JS/TS ont parfois tendance à en faire un peu trop une religion
    C’est un peu un phénomène Blub
  • Rust demande de gérer explicitement l’allocation mémoire et les types, donc le développement est plus difficile, mais on y trouve aussi beaucoup de logiciels de haute qualité
    Au final, c’est aussi un élément marketing, mais il est vrai qu’en moyenne le niveau de finition est élevé
• La formule « Compacting garbage collector, written in very unsafe Rust » m’a beaucoup fait rire
  • Hors sujet, mais les anciennes intros cracktro me manquent
    J’imagine une intro Ikari s’affichant avant le démarrage de l’OS
• Je me demande ce qu’il vaut face aux moteurs JS existants
  • Les benchmarks de javascript-zoo permettent d’avoir une comparaison approximative
  • Ce moteur peut être embarqué directement dans un programme Rust
    C’est du Rust natif complet, sans liaison C/C++
    On peut ajouter du scripting JS à un serveur en binaire unique de 40 Mo
    C’est vraiment chouette de voir apparaître plusieurs moteurs JS basés sur Rust
• L’un des plus grands avantages de Rust est la sécurité mémoire, alors pourquoi avoir utilisé un GC en unsafe ?
  • Comme il n’existe pas de GC hautes performances en Rust, implémenter en unsafe un nouveau système de gestion mémoire est un choix rationnel
    Tant que la zone unsafe reste minimale, cela me paraît acceptable
  • En réalité, même la bibliothèque standard avec Vec utilise de l’unsafe en interne
    L’important est de limiter l’unsafe à de petites zones vérifiables
    Une implémentation de GC fait partie de ces zones d’exception
  • Même l’unsafe de Rust n’a pas un champ d’undefined behavior aussi large qu’en C++
    Si je devais moi aussi écrire un runtime JS en Rust, je commencerais par une implémentation sûre et je n’utiliserais unsafe qu’en cas de besoin
  • unsafe est un outil qui permet au développeur de contrôler directement ce que le compilateur ne comprend pas
    Pour implémenter un GC hautes performances, certaines parties sont inévitablement nécessaires
  • Personnellement, je trouve que l’accent mis sur la sécurité mémoire en Rust est exagéré
    Rust est simplement un langage impératif rapide et de qualité
• Je ne vois pas de licence
  • C’était un oubli. C’est désormais publié sous licence MIT
  • De manière générale, je suis plutôt favorable à une orientation qui n’autorise pas les usages abusifs par les grandes entreprises
• Certains commentaires semblaient mal comprendre le fait que « Rust n’est pas un langage à garbage collection »
  • Rust n’est pas un langage à GC ; le comptage de références ne s’applique que lorsqu’on utilise Rc ou Arc