▲

Brimstone - Rust로 작성된 ES2025 JavaScript 엔진

 (github.com/Hans-Halverson)
4P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Rust로 처음부터 구현된 JavaScript 엔진으로, ECMAScript 사양을 거의 완전하게 지원하는 구조
  • 현재 ECMAScript 언어의 97% 이상을 통과하며, test262 기반 테스트로 검증된 상태
  • V8의 Ignition 설계와 SerenityOS의 LibJS에서 영감을 받아, 대부분의 구성요소를 의존성 최소화 방식으로 직접 구현
  • 바이트코드 VM, 압축형 가비지 컬렉터, 커스텀 RegExp 엔진과 파서를 포함해 사양에 맞는 내장 객체와 함수 제공
  • 아직 프로덕션용으로는 미완성이지만, ES2025 수준의 기능을 갖춘 Rust 기반 JS 엔진 개발의 중요한 진전

Brimstone 개요

  • Brimstone은 Rust로 완전 새로 작성된 JavaScript 엔진으로, ECMAScript 사양을 충실히 구현하는 것을 목표로 함
  • 현재 ECMAScript 언어의 97% 이상을 지원하며, test262 테스트를 통과
  • 아직 프로덕션 환경에서는 사용 준비가 되지 않은 진행 중인 프로젝트임

설계 및 구현

  • ECMAScript 사양을 직접 구현하며, V8과 SerenityOS의 LibJS에서 설계적 영감을 받음
  • 대부분의 엔진 구성요소를 의존성 없이 직접 구현하되, ICU4X만 예외적으로 사용
  • 주요 구성 요소:
    • V8 Ignition을 참고한 바이트코드 기반 VM
    • 매우 unsafe한 Rust 코드로 작성된 압축형 가비지 컬렉터
    • 커스텀 RegExp 엔진과 파서
    • 사양에 맞는 내장 객체 및 함수 구현

빌드 및 실행

  • 표준 Cargo 명령어로 빌드 및 실행 가능
    • cargo build로 bs 실행 파일 생성
    • cargo run으로 소스에서 직접 실행
  • JavaScript 파일 실행 예시: 
    cargo build
./target/debug/bs ./hello.js
Hello world!

테스트 체계

  • 공식 test262를 포함한 1·3자 통합 테스트 세트를 활용
  • 커스텀 통합 테스트 러너 포함 (cargo brimstone-test 명령으로 실행)
  • 단위 및 스냅샷 테스트는 cargo test로 수행
  • 추가 테스트 정보는 tests/README.md에서 확인 가능

미구현 기능

  • ES2024까지의 모든 기능과 2025년 2월 TC39 회의 기준 Stage 4 제안 대부분 구현
  • 아직 미지원 기능:
    • SharedArrayBuffer
    • Atomics
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • 작성자인 나임. 이 프로젝트가 소개된 걸 보니 정말 반가움
    @ivankra가 javascript-zoo에 추가하고 벤치마크를 돌려준 덕분에 감사한 마음임
    지난 3년 동안 완성도와 성능을 높이기 위해 꾸준히 시간을 들여온 취미 프로젝트였음
  • 간단히 비교하자면, 릴리스 빌드 기준으로 Boa는 23MB, Brimstone은 6.3MB 정도임
    Boa 수준의 기능을 채우고 프로덕션용으로 강화하면 크기가 커질 수도 있겠지만, 이 작은 크기로 97%의 스펙을 통과하는 건 꽤 인상적임
    • Boa는 내부에 Unicode 테이블을 포함하고 있음
      Brimstone은 그렇지 않아서 그게 크기 차이의 대부분을 차지함
      Unicode 처리를 제대로 하려면 수 MB의 데이터가 필요하기 때문에, 요즘은 작은 실행 파일을 만드는 게 쉽지 않음
      Unicode 지원이 필수라면 최소한의 크기 한계가 생김
    • 혹시 크기 최적화를 따로 적용했는지 궁금함
      기본 설정은 보통 성능 중심이라, codegen-units=1이나 panic 제거 같은 옵션을 바꾸면 결과가 달라질 수도 있음
    • 마지막 몇 퍼센트를 채우는 과정에서 크기가 불균형하게 커질 수도 있음
      Boa는 약 91%만 통과하니까, Brimstone이 더 완성도 높음
      소규모 프로젝트일수록 코드가 작고 깔끔하며 유지보수하기 쉬움
      협업에는 언제나 일정한 오버헤드가 따름
  • Boa와 비교해줄 수 있는지 궁금함
    Boa 저장소
    • 여기 벤치마크 결과를 보면, 1인 프로젝트치고는 놀라울 정도로 완성도가 높음
      기능은 Boa와 거의 비슷하고, 일부 벤치마크에서는 속도가 두 배 빠름
  • 왜 Rust로 작성된 프로젝트는 항상 “Rust로 작성됨”을 강조하는지 궁금함
    • 예전에 “Lisp로 작성됨”, “Ruby로 작성됨”, “JavaScript로 작성됨” 같은 시절도 있었음
      자연스러운 흐름이라 생각함
    • Rust는 (unsafe가 없다면) 특정 버그 클래스가 원천적으로 차단된다는 점에서 의미가 있음
      다만 이 프로젝트는 unsafe를 꽤 많이 쓴다고 함
    • Rust 생태계에 투자한 사람들에게는 새로운 프로젝트를 발견할 신호가 되기 때문임
    • Rust는 괜찮은 언어지만, JS/TS에서 넘어온 젊은 개발자들이 과하게 신봉하는 경향이 있음
      일종의 Blub 현상 같음
    • Rust는 메모리 할당과 타입을 명시적으로 다뤄야 해서 개발 난이도가 높지만, 그만큼 품질이 높은 소프트웨어가 많음
      결국 마케팅 요소이긴 하지만, 평균적으로 완성도가 높은 건 사실임
  • “Compacting garbage collector, written in very unsafe Rust”라는 문구가 너무 웃겼음
    • 주제와는 다르지만, 예전 cracktro 인트로가 그리움
      OS 부팅 전에 Ikari 인트로가 뜨는 걸 상상해봄
  • 기존 JS 엔진들과 비교하면 어떤지 궁금함
    • javascript-zoo의 벤치마크를 보면 대략적인 비교가 가능함
    • 이 엔진은 Rust 프로그램에 직접 임베드할 수 있음
      C/C++ 링크 없이 완전한 Rust 네이티브
      40MB짜리 단일 바이너리 서버에 JS 스크립팅을 추가할 수 있음
      Rust 기반 JS 엔진이 여러 개 생긴 건 정말 멋진 일임
  • Rust의 가장 큰 장점 중 하나가 메모리 안전성인데, 왜 굳이 unsafe GC를 썼는지 의문임
    • Rust에는 고성능 GC가 없으니, unsafe로 새로운 메모리 관리 체계를 구현하는 게 합리적임
      unsafe 영역을 최소화하면 괜찮다고 생각함
    • 사실 Vec 같은 표준 라이브러리조차 내부적으로 unsafe를 사용함
      중요한 건 unsafe를 작은 영역에 한정해 검증 가능하게 만드는 것임
      GC 구현은 그 예외적인 영역임
    • Rust의 unsafe조차 C++처럼 undefined behavior가 넓지 않음
      나라도 JS 런타임을 Rust로 만든다면, 우선 안전하게 구현하고 필요할 때만 unsafe를 쓸 것임
    • unsafe는 컴파일러가 이해하지 못하는 부분을 개발자가 직접 제어하기 위한 도구임
      고성능 GC를 구현하려면 어쩔 수 없이 필요한 부분임
    • 개인적으로는 Rust의 메모리 안전성 강조가 과장되었다고 느낌
      Rust는 그냥 빠르고 좋은 명령형 언어임
  • 라이선스가 보이지 않음
    • 실수였음. 이제 MIT 라이선스로 공개함
    • 기본적으로 대기업의 착취적 사용을 허용하지 않는 방향을 반기는 입장임
  • “Rust는 가비지 컬렉션 언어가 아니다”라는 점을 오해하는 댓글이 있었음
    • Rust는 GC 언어가 아님, Rc나 Arc를 쓸 때만 참조 카운팅이 적용됨
답변달기