Brimstone - Engine JavaScript ES2025 được viết bằng Rust

• Một engine JavaScript được triển khai hoàn toàn từ đầu bằng Rust, với kiến trúc hỗ trợ gần như đầy đủ đặc tả ECMAScript
• Hiện đã vượt qua hơn 97% bài kiểm tra của ngôn ngữ ECMAScript, được xác thực bằng bộ kiểm thử dựa trên test262
• Lấy cảm hứng từ thiết kế Ignition của V8 và LibJS của SerenityOS, đồng thời tự triển khai hầu hết các thành phần theo hướng giảm thiểu phụ thuộc
• Bao gồm VM bytecode, bộ gom rác nén, engine RegExp tùy biến và parser, cùng các đối tượng và hàm dựng sẵn tuân theo đặc tả
• Dù vẫn chưa hoàn thiện để dùng trong production, đây là một bước tiến quan trọng trong việc phát triển engine JS nền tảng Rust với mức tính năng tương đương ES2025

---

Tổng quan về Brimstone

• Brimstone là một engine JavaScript được viết mới hoàn toàn bằng Rust, hướng tới việc hiện thực trung thực đặc tả ECMAScript
• Hiện hỗ trợ hơn 97% ngôn ngữ ECMAScript và đã vượt qua các bài kiểm tra test262
• Đây vẫn là một dự án đang được phát triển, chưa sẵn sàng để sử dụng trong môi trường production

Thiết kế và triển khai

• Tự hiện thực trực tiếp đặc tả ECMAScript, đồng thời lấy cảm hứng thiết kế từ V8 và LibJS của SerenityOS
• Tự triển khai phần lớn các thành phần của engine mà không cần phụ thuộc, ngoại lệ duy nhất là ICU4X
• Các thành phần chính:
  • VM dựa trên bytecode tham khảo V8 Ignition
  • Bộ gom rác nén được viết bằng mã Rust rất nhiều unsafe
  • Engine RegExp tùy biến và parser
  • Hiện thực các đối tượng và hàm dựng sẵn tuân theo đặc tả

Build và chạy

• Có thể build và chạy bằng các lệnh Cargo tiêu chuẩn
  • Dùng cargo build để tạo file thực thi bs
  • Dùng cargo run để chạy trực tiếp từ mã nguồn
• Ví dụ chạy file JavaScript:

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

Hệ thống kiểm thử

• Sử dụng bộ kiểm thử tích hợp của bên thứ nhất và bên thứ ba, bao gồm test262 chính thức
• Có kèm trình chạy kiểm thử tích hợp tùy biến (chạy bằng lệnh cargo brimstone-test)
• Kiểm thử đơn vị và snapshot được chạy bằng cargo test
• Có thể xem thêm thông tin kiểm thử trong tests/README.md

Các tính năng chưa được hiện thực

• Đã hiện thực mọi tính năng đến ES2024 và phần lớn các đề xuất Stage 4 tính đến cuộc họp TC39 tháng 2/2025
• Các tính năng hiện vẫn chưa được hỗ trợ:
  • SharedArrayBuffer
  • Atomics

[shakespeares]

Đỉnh thật..

[GN⁺]

Ý kiến trên Hacker News

• Tôi là tác giả. Thật sự rất vui khi thấy dự án này được giới thiệu
  Cảm ơn @ivankra đã thêm nó vào javascript-zoo và chạy benchmark
  Đây là một dự án làm vì sở thích mà tôi đã đều đặn dành thời gian trong 3 năm qua để nâng cao độ hoàn thiện và hiệu năng
• Nếu so sánh đơn giản thì ở bản build phát hành, Boa khoảng 23MB còn Brimstone khoảng 6.3MB
  Dù có thể kích thước sẽ tăng nếu bổ sung mức tính năng tương đương Boa và gia cố để dùng production, việc vượt qua 97% spec với kích thước nhỏ như vậy vẫn khá ấn tượng
  • Boa có tích hợp sẵn bảng Unicode bên trong
    Brimstone thì không, nên đó là phần lớn nguyên nhân tạo ra chênh lệch kích thước
    Để xử lý Unicode đúng cách thì cần dữ liệu cỡ vài MB, nên thời nay không dễ để tạo ra file thực thi nhỏ
    Nếu hỗ trợ Unicode là bắt buộc thì sẽ có một giới hạn tối thiểu về kích thước
  • Không rõ có áp dụng tối ưu hóa riêng cho kích thước hay không
    Thiết lập mặc định thường ưu tiên hiệu năng, nên nếu đổi các tùy chọn như codegen-units=1 hoặc loại bỏ panic thì kết quả có thể sẽ khác
  • Quá trình lấp nốt vài phần trăm cuối cùng có thể khiến kích thước tăng không cân xứng
    Boa chỉ vượt qua khoảng 91%, nên Brimstone hoàn thiện hơn
    Dự án quy mô nhỏ thường nhỏ gọn, sạch sẽ và dễ bảo trì hơn
    Cộng tác luôn đi kèm một mức overhead nhất định
• Tôi tò mò liệu có thể so sánh với Boa không
  Kho lưu trữ Boa
  • Kết quả benchmark ở đây cho thấy với một dự án do 1 người làm thì mức độ hoàn thiện đáng kinh ngạc
    Tính năng gần như tương đương Boa, và ở một số benchmark thì nhanh gấp đôi
• Tôi thắc mắc vì sao các dự án viết bằng Rust lúc nào cũng nhấn mạnh là “được viết bằng Rust”
  • Trước đây cũng từng có thời “được viết bằng Lisp”, “được viết bằng Ruby”, “được viết bằng JavaScript”
    Tôi nghĩ đó là một diễn biến tự nhiên
  • Rust có ý nghĩa ở chỗ (nếu không có unsafe) một số nhóm lỗi nhất định bị chặn từ gốc
    Tuy nhiên dự án này được nói là dùng unsafe khá nhiều
  • Vì với những người đã đầu tư vào hệ sinh thái Rust, đó là một tín hiệu để khám phá dự án mới
  • Rust là một ngôn ngữ ổn, nhưng những lập trình viên trẻ chuyển sang từ JS/TS có xu hướng tôn sùng nó quá mức
    Nó giống một kiểu hiện tượng Blub
  • Rust buộc phải xử lý tường minh việc cấp phát bộ nhớ và kiểu dữ liệu nên độ khó phát triển cao hơn, nhưng đổi lại có nhiều phần mềm chất lượng cao
    Cuối cùng đây vẫn là một yếu tố marketing, nhưng đúng là trung bình mức độ hoàn thiện cao hơn
• Cụm “Compacting garbage collector, written in very unsafe Rust” làm tôi thấy quá buồn cười
  • Hơi lạc đề nhưng tôi nhớ những intro cracktro ngày xưa
    Tôi tưởng tượng cảnh intro của Ikari hiện ra trước khi OS khởi động
• Tôi tò mò nếu so với các JS engine hiện có thì thế nào
  • Có thể xem so sánh tương đối qua benchmark của javascript-zoo
  • Engine này có thể được nhúng trực tiếp vào chương trình Rust
    Rust native hoàn toàn, không cần liên kết C/C++
    Có thể thêm scripting JS vào một server nhị phân đơn 40MB
    Việc xuất hiện nhiều JS engine nền Rust thật sự rất tuyệt
• Một trong những ưu điểm lớn nhất của Rust là an toàn bộ nhớ, vậy tại sao lại cố tình dùng GC unsafe?
  • Rust không có GC hiệu năng cao, nên việc dùng unsafe để hiện thực một cơ chế quản lý bộ nhớ mới là hợp lý
    Tôi nghĩ chỉ cần giảm tối đa vùng unsafe là ổn
  • Thực ra ngay cả thư viện chuẩn như Vec bên trong cũng dùng unsafe
    Điều quan trọng là giới hạn unsafe vào những vùng nhỏ để có thể kiểm chứng
    Hiện thực GC là một trong những vùng ngoại lệ như vậy
  • Ngay cả unsafe của Rust cũng không có phạm vi undefined behavior rộng như C++
    Nếu tôi làm JS runtime bằng Rust thì cũng sẽ ưu tiên hiện thực an toàn trước, rồi chỉ dùng unsafe khi cần
  • unsafe là công cụ để lập trình viên tự kiểm soát những phần mà compiler không hiểu được
    Để hiện thực GC hiệu năng cao thì có những chỗ bắt buộc phải dùng
  • Cá nhân tôi cảm thấy việc Rust nhấn mạnh an toàn bộ nhớ có phần bị phóng đại
    Rust đơn giản là một ngôn ngữ mệnh lệnh nhanh và tốt
• Tôi không thấy giấy phép đâu cả
  • Là do sơ suất. Giờ tôi đã phát hành theo giấy phép MIT
  • Về cơ bản tôi hoan nghênh định hướng không cho phép các tập đoàn lớn khai thác một cách bóc lột
• Có bình luận hiểu sai rằng “Rust không phải là ngôn ngữ có garbage collection”
  • Rust không phải ngôn ngữ GC, chỉ khi dùng Rc hoặc Arc thì mới áp dụng reference counting