Brimstone - motor JavaScript ES2025 escrito en Rust

• Motor JavaScript implementado desde cero en Rust, con una arquitectura que soporta casi por completo la especificación ECMAScript
• Actualmente supera más del 97% del lenguaje ECMAScript, validado con pruebas basadas en test262
• Inspirado en el diseño de Ignition de V8 y en LibJS de SerenityOS, implementa directamente la mayoría de sus componentes con un enfoque de mínimas dependencias
• Incluye una VM de bytecode, un garbage collector compactante, un motor RegExp personalizado y un parser, además de objetos y funciones integrados conformes a la especificación
• Aún no está terminado para uso en producción, pero representa un avance importante en el desarrollo de un motor JS en Rust con capacidades de nivel ES2025

---

Resumen de Brimstone

• Brimstone es un motor JavaScript completamente nuevo escrito en Rust, cuyo objetivo es implementar fielmente la especificación ECMAScript
• Actualmente soporta más del 97% del lenguaje ECMAScript y pasa las pruebas de test262
• Sigue siendo un proyecto en desarrollo y todavía no está listo para usarse en producción

Diseño e implementación

• Implementa directamente la especificación ECMAScript y toma inspiración de diseño de V8 y de LibJS de SerenityOS
• La mayoría de los componentes del motor están implementados directamente sin dependencias, con ICU4X como única excepción
• Componentes principales:
  • VM basada en bytecode inspirada en V8 Ignition
  • Garbage collector compactante escrito con código Rust muy unsafe
  • Motor RegExp personalizado y parser
  • Implementación de objetos y funciones integrados conforme a la especificación

Compilación y ejecución

• Se puede compilar y ejecutar con comandos estándar de Cargo
  • cargo build genera el ejecutable bs
  • cargo run lo ejecuta directamente desde el código fuente
• Ejemplo de ejecución de un archivo JavaScript:

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

Sistema de pruebas

• Utiliza un conjunto de pruebas de integración de primera y tercera parte, incluyendo el oficial test262
• Incluye un runner de pruebas de integración personalizado (se ejecuta con el comando cargo brimstone-test)
• Las pruebas unitarias y de snapshot se ejecutan con cargo test
• Se puede consultar más información de pruebas en tests/README.md

Funcionalidades no implementadas

• Ya implementa todas las funciones hasta ES2024 y la mayoría de las propuestas Stage 4 según la reunión de TC39 de febrero de 2025
• Funcionalidades aún no soportadas:
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Está brutal..

[GN⁺]

Comentarios de Hacker News

• Soy el autor. Me da muchísimo gusto ver que presentaron este proyecto.
  Gracias a @ivankra por añadirlo a javascript-zoo y correr los benchmarks.
  Ha sido un proyecto de hobby al que le he dedicado tiempo de forma constante durante los últimos 3 años para mejorar su nivel de terminación y rendimiento.
• Para compararlo de forma simple, en build de release Boa pesa unos 23 MB y Brimstone alrededor de 6.3 MB.
  Puede que crezca si alcanza el nivel de funciones de Boa y se refuerza para producción, pero aun así es bastante impresionante que con este tamaño pase el 97% de la especificación.
  • Boa incluye internamente tablas Unicode.
    Brimstone no, y eso explica la mayor parte de la diferencia de tamaño.
    Como para manejar Unicode correctamente se necesitan varios MB de datos, hoy en día no es fácil hacer ejecutables pequeños.
    Si el soporte de Unicode es obligatorio, hay un límite mínimo de tamaño.
  • Me pregunto si aplicaste alguna optimización específica de tamaño.
    La configuración por defecto normalmente prioriza el rendimiento, así que cambiar opciones como codegen-units=1 o quitar panic podría alterar el resultado.
  • En ese último porcentaje también puede crecer el tamaño de forma desproporcionada.
    Boa solo pasa alrededor del 91%, así que Brimstone está más completo.
    Mientras más pequeño es el proyecto, más compacto, limpio y fácil de mantener suele ser el código.
    La colaboración siempre trae cierto overhead.
• Me gustaría ver una comparación con Boa.
  Repositorio de Boa
  • Si ves estos resultados de benchmark, para ser un proyecto de una sola persona tiene un nivel de terminación sorprendentemente alto.
    En funciones está casi al nivel de Boa, y en algunos benchmarks es dos veces más rápido.
• Me pregunto por qué los proyectos hechos en Rust siempre enfatizan tanto el “hecho en Rust”.
  • Antes también hubo épocas de “hecho en Lisp”, “hecho en Ruby” o “hecho en JavaScript”.
    Me parece algo natural.
  • Rust tiene sentido porque, si no hay unsafe, ciertas clases de bugs quedan bloqueadas de raíz.
    Aunque dicen que este proyecto usa bastante unsafe.
  • Porque para la gente que ha invertido en el ecosistema Rust, eso sirve como una señal para descubrir proyectos nuevos.
  • Rust es un buen lenguaje, pero los desarrolladores jóvenes que vienen de JS/TS tienden a idolatrarlo demasiado.
    Es una especie de efecto Blub.
  • Rust obliga a tratar explícitamente la asignación de memoria y los tipos, así que desarrollar es más difícil, pero por eso mismo hay mucho software de alta calidad.
    Al final sí es un elemento de marketing, pero también es cierto que en promedio el nivel de terminación es alto.
• La frase “Compacting garbage collector, written in very unsafe Rust” me dio muchísima risa.
  • No tiene que ver con el tema, pero extraño las viejas intros cracktro.
    Me imaginé una intro de Ikari apareciendo antes de arrancar el SO.
• Me pregunto cómo se compara con los motores de JS existentes.
  • En los benchmarks de javascript-zoo se puede hacer una comparación aproximada.
  • Este motor se puede embeber directamente en programas Rust.
    Es completamente nativo de Rust, sin enlazar C/C++.
    Puedes agregar scripting en JS a un servidor en un solo binario de 40 MB.
    Es realmente genial que ya existan varios motores JS basados en Rust.
• Una de las mayores ventajas de Rust es la seguridad de memoria, así que me pregunto por qué usar a propósito un GC unsafe.
  • Como en Rust no hay un GC de alto rendimiento, es razonable implementar un nuevo sistema de gestión de memoria con unsafe.
    Si mantienes el área unsafe al mínimo, me parece bien.
  • De hecho, incluso la biblioteca estándar, como Vec, usa unsafe internamente.
    Lo importante es limitar unsafe a una zona pequeña para que se pueda verificar.
    Implementar un GC es una de esas áreas excepcionales.
  • Incluso el unsafe de Rust no tiene un rango tan amplio de undefined behavior como C++.
    Si yo hiciera un runtime de JS en Rust, primero lo implementaría de forma segura y solo usaría unsafe cuando fuera necesario.
  • unsafe es una herramienta para que el desarrollador controle directamente las partes que el compilador no puede comprender.
    Si quieres implementar un GC de alto rendimiento, hay partes donde simplemente es inevitable.
  • En lo personal, siento que el énfasis en la seguridad de memoria de Rust está exagerado.
    Rust es simplemente un lenguaje imperativo rápido y bueno.
• No veo la licencia.
  • Fue un descuido. Ahora ya está publicado bajo licencia MIT.
  • En general, me agrada la idea de no permitir el uso explotador por parte de grandes corporaciones.
• Había comentarios que malinterpretaban el punto de que “Rust no es un lenguaje con recolección de basura”.
  • Rust no es un lenguaje con GC; el conteo de referencias solo se aplica cuando usas Rc o Arc.