Brimstone - Mesin JavaScript ES2025 yang Ditulis dengan Rust

• Mesin JavaScript yang diimplementasikan dari nol dengan Rust, dengan arsitektur yang mendukung spesifikasi ECMAScript hampir sepenuhnya
• Saat ini telah lolos lebih dari 97% bahasa ECMAScript, dan telah diverifikasi dengan pengujian berbasis test262
• Terinspirasi oleh desain Ignition milik V8 dan LibJS dari SerenityOS, dengan sebagian besar komponen diimplementasikan sendiri dengan pendekatan meminimalkan dependensi
• Menyertakan VM bytecode, garbage collector kompak, mesin RegExp kustom, dan parser, serta menyediakan objek dan fungsi bawaan yang sesuai spesifikasi
• Meski belum selesai untuk penggunaan produksi, ini merupakan kemajuan penting dalam pengembangan mesin JS berbasis Rust dengan kemampuan setingkat ES2025

---

Ikhtisar Brimstone

• Brimstone adalah mesin JavaScript yang sepenuhnya baru ditulis dengan Rust, dengan tujuan mengimplementasikan spesifikasi ECMAScript secara setia
• Saat ini mendukung lebih dari 97% bahasa ECMAScript dan lolos pengujian test262
• Ini masih merupakan proyek yang sedang dikembangkan dan belum siap digunakan di lingkungan produksi

Desain dan implementasi

• Mengimplementasikan spesifikasi ECMAScript secara langsung, dengan inspirasi desain dari V8 dan LibJS milik SerenityOS
• Sebagian besar komponen mesin diimplementasikan sendiri tanpa dependensi, dengan ICU4X sebagai satu-satunya pengecualian
• Komponen utama:
  • VM berbasis bytecode yang merujuk pada V8 Ignition
  • Garbage collector kompak yang ditulis dengan kode Rust yang sangat unsafe
  • Mesin RegExp kustom dan parser
  • Implementasi objek dan fungsi bawaan yang sesuai spesifikasi

Build dan menjalankan

• Dapat di-build dan dijalankan dengan perintah Cargo standar
  • cargo build membuat berkas eksekusi bs
  • cargo run menjalankan langsung dari source
• Contoh menjalankan berkas JavaScript:

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

Sistem pengujian

• Memanfaatkan rangkaian pengujian integrasi pihak pertama dan pihak ketiga, termasuk test262 resmi
• Menyertakan runner pengujian integrasi kustom (dijalankan dengan perintah cargo brimstone-test)
• Pengujian unit dan snapshot dijalankan dengan cargo test
• Informasi pengujian tambahan tersedia di tests/README.md

Fitur yang belum diimplementasikan

• Sudah mengimplementasikan semua fitur hingga ES2024 dan sebagian besar proposal Stage 4 berdasarkan rapat TC39 Februari 2025
• Fitur yang masih belum didukung:
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Mantap banget..

[GN⁺]

Komentar Hacker News

• Saya penulisnya. Senang sekali melihat proyek ini dibahas
  Terima kasih kepada @ivankra yang menambahkannya ke javascript-zoo dan menjalankan benchmark
  Ini adalah proyek hobi yang saya tekuni secara konsisten selama 3 tahun terakhir untuk meningkatkan kematangan dan performa
• Sebagai perbandingan sederhana, pada build rilis Boa berukuran sekitar 23MB, sedangkan Brimstone sekitar 6.3MB
  Ukurannya mungkin akan membesar jika fiturnya disejajarkan dengan Boa dan diperkuat untuk penggunaan produksi, tetapi cukup mengesankan bahwa dengan ukuran sekecil ini ia lulus 97% spesifikasi
  • Boa menyertakan tabel Unicode di dalamnya
    Brimstone tidak, dan itu mencakup sebagian besar perbedaan ukuran
    Untuk menangani Unicode dengan benar, dibutuhkan data beberapa MB, jadi membuat executable kecil bukan hal yang mudah saat ini
    Jika dukungan Unicode wajib ada, maka ada batas ukuran minimum
  • Penasaran apakah ada optimasi ukuran khusus yang diterapkan
    Konfigurasi default biasanya berfokus pada performa, jadi hasilnya bisa berubah jika opsi seperti codegen-units=1 atau penghapusan panic diubah
  • Mengisi beberapa persen terakhir bisa membuat ukuran membesar secara tidak proporsional
    Boa hanya meluluskan sekitar 91%, jadi Brimstone lebih matang
    Proyek yang lebih kecil cenderung memiliki kode yang kecil, rapi, dan mudah dirawat
    Kolaborasi selalu membawa overhead tertentu
• Penasaran apakah bisa dibandingkan dengan Boa
  Repositori Boa
  • Jika melihat hasil benchmark di sini, untuk proyek satu orang tingkat kematangannya sangat mengejutkan
    Fungsinya hampir setara dengan Boa, dan pada beberapa benchmark dua kali lebih cepat
• Penasaran kenapa proyek yang ditulis dengan Rust selalu menekankan “ditulis dengan Rust”
  • Dulu juga ada masa ketika orang menekankan “ditulis dengan Lisp”, “ditulis dengan Ruby”, atau “ditulis dengan JavaScript”
    Menurut saya itu alur yang wajar
  • Rust punya makna karena, (jika tidak ada unsafe), kelas bug tertentu dapat dicegah dari akarnya
    Namun katanya proyek ini cukup banyak memakai unsafe
  • Bagi orang yang sudah berinvestasi di ekosistem Rust, itu menjadi sinyal untuk menemukan proyek baru
  • Rust adalah bahasa yang bagus, tetapi pengembang muda yang datang dari JS/TS cenderung terlalu memujanya
    Rasanya seperti semacam fenomena Blub
  • Rust menuntut penanganan alokasi memori dan tipe secara eksplisit, jadi tingkat kesulitannya tinggi, tetapi karena itu juga banyak menghasilkan perangkat lunak berkualitas tinggi
    Pada akhirnya memang unsur pemasaran, tetapi rata-rata tingkat kematangannya tinggi
• Kalimat “Compacting garbage collector, written in very unsafe Rust” sangat lucu
  • Agak di luar topik, tapi saya rindu intro cracktro zaman dulu
    Saya membayangkan intro Ikari muncul sebelum OS boot
• Penasaran bagaimana jika dibandingkan dengan engine JS yang sudah ada
  • Melihat benchmark javascript-zoo, kita bisa mendapat gambaran perbandingan kasarnya
  • Engine ini bisa di-embed langsung ke program Rust
    Sepenuhnya native Rust tanpa tautan C/C++
    Kita bisa menambahkan scripting JS ke server biner tunggal berukuran 40MB
    Keren sekali melihat ada beberapa engine JS berbasis Rust bermunculan
• Salah satu keunggulan terbesar Rust adalah keamanan memori, jadi kenapa sengaja memakai GC unsafe terasa janggal
  • Karena Rust tidak punya GC berperforma tinggi, masuk akal untuk mengimplementasikan sistem manajemen memori baru dengan unsafe
    Selama area unsafe diminimalkan, menurut saya tidak masalah
  • Faktanya, bahkan pustaka standar seperti Vec pun secara internal menggunakan unsafe
    Yang penting adalah membatasi unsafe pada area kecil agar bisa diverifikasi
    Implementasi GC adalah salah satu area pengecualian itu
  • Bahkan unsafe di Rust pun tidak seluas undefined behavior seperti di C++
    Kalau saya membuat runtime JS dengan Rust, saya juga akan mengimplementasikannya dengan aman terlebih dahulu lalu memakai unsafe hanya saat diperlukan
  • unsafe adalah alat agar pengembang mengendalikan langsung bagian yang tidak dipahami compiler
    Untuk mengimplementasikan GC berperforma tinggi, ada bagian yang memang tak terhindarkan
  • Secara pribadi saya merasa penekanan pada keamanan memori di Rust agak dibesar-besarkan
    Rust hanyalah bahasa imperatif yang cepat dan bagus
• Saya tidak melihat lisensinya
  • Itu kelalaian. Sekarang sudah dirilis dengan lisensi MIT
  • Pada dasarnya saya menyambut pendekatan yang tidak mengizinkan penggunaan eksploitatif oleh perusahaan besar
• Ada komentar yang salah paham soal “Rust bukan bahasa dengan garbage collection”
  • Rust bukan bahasa GC, reference counting hanya berlaku saat memakai Rc atau Arc