# Brimstone - Rust로 작성된 ES2025 JavaScript 엔진

> Clean Markdown view of GeekNews topic #24425. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24425](https://news.hada.io/topic?id=24425)
- GeekNews Markdown: [https://news.hada.io/topic/24425.md](https://news.hada.io/topic/24425.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-17T17:33:54+09:00
- Updated: 2025-11-17T17:33:54+09:00
- Original source: [github.com/Hans-Halverson](https://github.com/Hans-Halverson/brimstone)
- Points: 5
- Comments: 2

## Summary

Rust로 완전히 새로 작성된 **JavaScript 엔진 Brimstone**이 ECMAScript 사양의 **97% 이상을 통과**하며 주목받고 있습니다. **V8의 Ignition VM**과 **SerenityOS의 LibJS**에서 영감을 얻었지만, 대부분의 구성요소를 **의존성 없이 직접 구현**해 Rust 생태계에서 보기 드문 수준의 독립성과 정밀도를 보여줍니다. 아직 프로덕션 단계는 아니지만, **ES2025 수준의 기능을 갖춘 Rust 기반 JS 엔진**이라는 점에서 차세대 런타임이나 임베디드 환경 개발자에게 흥미로운 실험대가 될 만합니다. Rust로 JS를 “다시 짜본다”는 발상 자체가 개발자 감성을 자극하네요.

## Topic Body

- **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**

## Comments



### Comment 46554

- Author: shakespeares
- Created: 2025-11-19T15:25:51+09:00
- Points: 1

대박이네요..

### Comment 46433

- Author: neo
- Created: 2025-11-17T17:33:55+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45944337) 
- 작성자인 나임. 이 프로젝트가 소개된 걸 보니 정말 반가움  
  @ivankra가 [javascript-zoo](https://github.com/ivankra/javascript-zoo)에 추가하고 벤치마크를 돌려준 덕분에 감사한 마음임  
  지난 3년 동안 **완성도와 성능**을 높이기 위해 꾸준히 시간을 들여온 **취미 프로젝트**였음
- 간단히 비교하자면, 릴리스 빌드 기준으로 Boa는 23MB, Brimstone은 6.3MB 정도임  
  Boa 수준의 기능을 채우고 프로덕션용으로 강화하면 크기가 커질 수도 있겠지만, 이 작은 크기로 **97%의 스펙을 통과**하는 건 꽤 인상적임
  - Boa는 내부에 [Unicode 테이블](https://github.com/boa-dev/boa/tree/main/core/icu_provider)을 포함하고 있음  
    Brimstone은 그렇지 않아서 그게 크기 차이의 대부분을 차지함  
    Unicode 처리를 제대로 하려면 수 MB의 데이터가 필요하기 때문에, 요즘은 작은 실행 파일을 만드는 게 쉽지 않음  
    **Unicode 지원**이 필수라면 최소한의 크기 한계가 생김
  - 혹시 크기 최적화를 따로 적용했는지 궁금함  
    기본 설정은 보통 **성능 중심**이라, `codegen-units=1`이나 panic 제거 같은 옵션을 바꾸면 결과가 달라질 수도 있음
  - 마지막 몇 퍼센트를 채우는 과정에서 크기가 불균형하게 커질 수도 있음  
    Boa는 약 91%만 통과하니까, Brimstone이 더 완성도 높음  
    소규모 프로젝트일수록 코드가 **작고 깔끔하며 유지보수하기 쉬움**  
    협업에는 언제나 일정한 **오버헤드**가 따름
- Boa와 비교해줄 수 있는지 궁금함  
  [Boa 저장소](https://github.com/boa-dev/boa)
  - [여기 벤치마크 결과](https://ivankra.github.io/javascript-zoo/?v8=true)를 보면, 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의 벤치마크](https://github.com/ivankra/javascript-zoo?tab=readme-ov-file#javascript-engines-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`를 쓸 때만 참조 카운팅이 적용됨