Brimstone - um motor JavaScript ES2025 escrito em Rust

• Motor JavaScript implementado do zero em Rust, com uma arquitetura que oferece suporte quase completo à especificação ECMAScript
• Atualmente passa em mais de 97% da linguagem ECMAScript, validado com testes baseados no test262
• Inspirado no design do Ignition do V8 e no LibJS do SerenityOS, implementa a maior parte dos componentes diretamente, com dependências mínimas
• Inclui VM de bytecode, coletor de lixo compactante, motor de RegExp personalizado e parser, além de fornecer objetos e funções embutidos em conformidade com a especificação
• Ainda não está pronto para produção, mas representa um avanço importante no desenvolvimento de um motor JS em Rust com recursos no nível do ES2025

---

Visão geral do Brimstone

• O Brimstone é um motor JavaScript totalmente novo escrito em Rust, com o objetivo de implementar fielmente a especificação ECMAScript
• Atualmente oferece suporte a mais de 97% da linguagem ECMAScript e passa nos testes do test262
• Ainda é um projeto em andamento e não está pronto para uso em produção

Design e implementação

• Implementa diretamente a especificação ECMAScript e busca inspiração de design no V8 e no LibJS do SerenityOS
• A maior parte dos componentes do motor é implementada diretamente sem dependências, com ICU4X como única exceção
• Principais componentes:
  • VM baseada em bytecode inspirada no V8 Ignition
  • Coletor de lixo compactante escrito em código Rust altamente unsafe
  • Motor de RegExp personalizado e parser
  • Implementação de objetos e funções embutidos em conformidade com a especificação

Build e execução

• Pode ser compilado e executado com os comandos padrão do Cargo
  • cargo build gera o executável bs
  • cargo run executa diretamente a partir do código-fonte
• Exemplo de execução de um arquivo JavaScript:

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

Sistema de testes

• Usa um conjunto de testes de integração oficiais e de terceiros, incluindo o test262
• Inclui um runner de testes de integração personalizado (executado com o comando cargo brimstone-test)
• Testes unitários e de snapshot são executados com cargo test
• Mais informações sobre testes podem ser encontradas em tests/README.md

Funcionalidades ainda não implementadas

• Implementa todos os recursos até o ES2024 e a maior parte das propostas Stage 4 com base na reunião do TC39 de fevereiro de 2025
• Recursos ainda não suportados:
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Incrível..

[GN⁺]

Comentários do Hacker News

• Sou o autor. Fico muito feliz em ver este projeto sendo apresentado
  Sou grato ao @ivankra por adicioná-lo ao javascript-zoo e rodar os benchmarks
  Foi um projeto de hobby no qual venho investindo tempo de forma constante nos últimos 3 anos para aumentar a qualidade e o desempenho
• Comparando de forma simples, em build de release o Boa tem 23 MB e o Brimstone fica em torno de 6,3 MB
  É possível que ele cresça se atingir o nível de recursos do Boa e for reforçado para uso em produção, mas passar em 97% da especificação com esse tamanho pequeno é bastante impressionante
  • O Boa inclui internamente tabelas Unicode
    O Brimstone não faz isso, e essa é a maior parte da diferença de tamanho
    Para lidar corretamente com Unicode, são necessários vários MB de dados, então hoje em dia não é fácil criar executáveis pequenos
    Se o suporte a Unicode for obrigatório, existe um limite mínimo de tamanho
  • Fiquei curioso se foi aplicada alguma otimização específica de tamanho
    A configuração padrão normalmente é voltada para desempenho, então mudar opções como codegen-units=1 ou remover panic pode alterar o resultado
  • O processo de preencher os últimos pontos percentuais pode aumentar o tamanho de forma desproporcional
    O Boa passa em cerca de 91%, então o Brimstone é mais completo
    Quanto menor o projeto, mais o código tende a ser pequeno, limpo e fácil de manter
    Sempre existe um certo overhead na colaboração
• Queria saber se dá para comparar com o Boa
  Repositório do Boa
  • Os resultados de benchmark aqui mostram que, para um projeto de uma pessoa só, o nível de acabamento é surpreendente
    Os recursos são quase equivalentes aos do Boa e, em alguns benchmarks, a velocidade é duas vezes maior
• Fico me perguntando por que projetos escritos em Rust sempre enfatizam que foram “escritos em Rust”
  • Já houve épocas de “escrito em Lisp”, “escrito em Ruby” e “escrito em JavaScript”
    Acho que é um fluxo natural
  • Rust tem significado porque (se não houver unsafe) certas classes de bugs são bloqueadas na origem
    Mas dizem que este projeto usa bastante unsafe
  • Para quem investiu no ecossistema Rust, isso serve como um sinal para descobrir novos projetos
  • Rust é uma linguagem boa, mas desenvolvedores jovens vindos de JS/TS tendem a tratá-la com devoção excessiva
    Parece uma espécie de fenômeno Blub
  • Rust exige lidar explicitamente com alocação de memória e tipos, então o desenvolvimento é mais difícil, mas em compensação há muito software de alta qualidade
    No fim, também é um elemento de marketing, mas é verdade que, em média, o nível de acabamento é mais alto
• A frase “Compacting garbage collector, written in very unsafe Rust” foi engraçada demais
  • Não tem a ver com o tema, mas sinto falta das antigas intros de cracktro
    Fiquei imaginando uma intro da Ikari aparecendo antes de o sistema operacional iniciar
• Fiquei curioso sobre como ele se compara aos motores JS existentes
  • Dá para ter uma comparação aproximada pelos benchmarks do javascript-zoo
  • Este motor pode ser embutido diretamente em programas Rust
    Totalmente nativo em Rust, sem dependência de link com C/C++
    Dá para adicionar scripting em JS a um servidor de binário único de 40 MB
    É realmente muito legal ver vários motores JS baseados em Rust surgindo
• Uma das maiores vantagens do Rust é a segurança de memória, então fico me perguntando por que foi usado um GC unsafe de propósito
  • Como Rust não tem um GC de alto desempenho, faz sentido implementar um novo sistema de gerenciamento de memória com unsafe
    Acho aceitável se a área unsafe for mantida no mínimo possível
  • Na verdade, até a biblioteca padrão, como Vec, usa unsafe internamente
    O importante é limitar o unsafe a áreas pequenas, para que possam ser verificadas
    Implementação de GC é uma dessas áreas excepcionais
  • Mesmo o unsafe do Rust não tem um alcance de undefined behavior tão amplo quanto o C++
    Se eu fosse fazer um runtime de JS em Rust, primeiro implementaria tudo de forma segura e só usaria unsafe quando necessário
  • unsafe é uma ferramenta para que o desenvolvedor controle diretamente partes que o compilador não consegue entender
    Para implementar um GC de alto desempenho, isso acaba sendo necessário em alguns pontos
  • Pessoalmente, acho que a ênfase na segurança de memória do Rust é exagerada
    Rust é simplesmente uma linguagem imperativa rápida e boa
• Não estou vendo a licença
  • Foi um descuido. Agora foi publicado sob a licença MIT
  • Em princípio, sou favorável a uma direção que não permita uso exploratório por grandes empresas
• Houve comentários entendendo mal o ponto de que “Rust não é uma linguagem com coleta de lixo”
  • Rust não é uma linguagem com GC; contagem de referências só é aplicada ao usar Rc ou Arc