Brimstone - เอนจิน JavaScript ES2025 ที่เขียนด้วย Rust

 (github.com/Hans-Halverson)
5 คะแนน โดย GN⁺ 2025-11-17 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอนจิน JavaScript ที่สร้างขึ้นใหม่ทั้งหมดด้วย Rust โดยมีโครงสร้างที่รองรับข้อกำหนด ECMAScript ได้เกือบครบถ้วน
  • ปัจจุบันผ่านการทดสอบของ ภาษา ECMAScript มากกว่า 97% และได้รับการตรวจสอบด้วยชุดทดสอบบนพื้นฐาน test262
  • ได้แรงบันดาลใจจาก สถาปัตยกรรม Ignition ของ V8 และ LibJS ของ SerenityOS พร้อมทั้งพัฒนาองค์ประกอบส่วนใหญ่ขึ้นเองแบบ ลดการพึ่งพาไลบรารีให้น้อยที่สุด
  • มีทั้ง bytecode VM, compact garbage collector, RegExp engine แบบคัสตอม และ parser รวมถึงมี built-in object และฟังก์ชันที่เป็นไปตามข้อกำหนด
  • แม้จะยัง ไม่สมบูรณ์สำหรับการใช้งานระดับโปรดักชัน แต่ก็ถือเป็นความก้าวหน้าสำคัญของการพัฒนา JS engine บน Rust ที่มีความสามารถระดับ ES2025

ภาพรวมของ Brimstone

  • Brimstone คือ เอนจิน JavaScript ที่เขียนขึ้นใหม่ทั้งหมดด้วย Rust โดยมีเป้าหมายเพื่อทำตามข้อกำหนด ECMAScript อย่างครบถ้วน
  • ขณะนี้รองรับ ภาษา ECMAScript มากกว่า 97% และผ่านการทดสอบ test262
  • ยังเป็น โครงการที่อยู่ระหว่างพัฒนา และยังไม่พร้อมสำหรับใช้งานในสภาพแวดล้อมระดับโปรดักชัน

การออกแบบและการพัฒนา

  • พัฒนาโดยอิงการทำตาม ข้อกำหนด ECMAScript โดยตรง และได้รับแรงบันดาลใจด้านการออกแบบจาก V8 และ LibJS ของ SerenityOS
  • องค์ประกอบส่วนใหญ่ของเอนจินถูกพัฒนาขึ้นเอง โดยไม่พึ่งพาไลบรารีภายนอก ยกเว้น ICU4X
  • องค์ประกอบหลักได้แก่:
    • VM แบบ bytecode ที่อ้างอิงแนวทางจาก V8 Ignition
    • compact garbage collector ที่เขียนด้วย Rust แบบ unsafe อย่างมาก
    • RegExp engine แบบคัสตอม และ parser
    • การทำตาม built-in object และฟังก์ชัน ให้สอดคล้องกับข้อกำหนด

การ build และการรัน

  • สามารถ build และรันได้ด้วย คำสั่ง Cargo มาตรฐาน
    • ใช้ cargo build เพื่อสร้างไฟล์ปฏิบัติการ bs
    • ใช้ cargo run เพื่อรันจากซอร์สโค้ดโดยตรง
  • ตัวอย่างการรันไฟล์ JavaScript: 
    cargo build
./target/debug/bs ./hello.js
Hello world!

ระบบทดสอบ

  • ใช้ชุดทดสอบ integration ทั้งจากทางการและของ third-party รวมถึง test262
  • มี custom integration test runner รวมอยู่ด้วย (รันด้วยคำสั่ง cargo brimstone-test)
  • การทดสอบแบบ unit และ snapshot ใช้ cargo test
  • ดูข้อมูลการทดสอบเพิ่มเติมได้ที่ tests/README.md

ฟีเจอร์ที่ยังไม่รองรับ

  • รองรับ ทุกฟีเจอร์จนถึง ES2024 และข้อเสนอ Stage 4 ส่วนใหญ่ตามการประชุม TC39 ณ เดือนกุมภาพันธ์ 2025
  • ฟีเจอร์ที่ยังไม่รองรับ:
    • SharedArrayBuffer
    • Atomics

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
shakespeares 2025-11-19

สุดยอดมาก..
 
GN⁺ 2025-11-17
ความคิดเห็นจาก Hacker News
  • ฉันคือผู้เขียนเอง ดีใจมากที่ได้เห็นโปรเจ็กต์นี้ถูกนำมาแนะนำ
    ขอบคุณ @ivankra ที่เพิ่มมันเข้าไปใน javascript-zoo และรันเบนช์มาร์กให้
    นี่เป็นโปรเจ็กต์งานอดิเรกที่ฉันค่อย ๆ ทุ่มเวลาให้มาตลอด 3 ปีเพื่อเพิ่มทั้งความสมบูรณ์และประสิทธิภาพ
  • ถ้าเทียบแบบง่าย ๆ ใน release build นั้น Boa อยู่ที่ราว 23MB ส่วน Brimstone อยู่ที่ประมาณ 6.3MB
    แม้ขนาดอาจใหญ่ขึ้นได้หากเติมฟีเจอร์ให้เทียบเท่า Boa และเสริมความพร้อมสำหรับ production แต่การที่ผ่านสเปกได้**97%**ด้วยขนาดเท่านี้ก็น่าประทับใจมาก
    • Boa รวม ตาราง Unicode ไว้ภายใน
      แต่ Brimstone ไม่ได้ทำแบบนั้น และนั่นคือสาเหตุหลักของความต่างด้านขนาด
      ถ้าจะรองรับ Unicode อย่างถูกต้องจำเป็นต้องมีข้อมูลหลาย MB ดังนั้นทุกวันนี้การทำไฟล์ปฏิบัติการให้เล็กจึงไม่ง่าย
      ถ้าต้องการรองรับ Unicode ก็จะมีขีดจำกัดขั้นต่ำของขนาดอยู่
    • สงสัยว่าได้ทำการปรับแต่งขนาดโดยเฉพาะหรือไม่
      ค่าปริยายมักจะเน้นประสิทธิภาพ ดังนั้นถ้าปรับตัวเลือกอย่าง codegen-units=1 หรือการตัด panic ออก ผลลัพธ์อาจเปลี่ยนไปได้
    • ระหว่างการไล่เก็บอีกไม่กี่เปอร์เซ็นต์สุดท้าย ขนาดอาจพองขึ้นแบบไม่สมส่วนก็ได้
      Boa ผ่านได้แค่ราว 91% ดังนั้น Brimstone จึงสมบูรณ์กว่ามาก
      ยิ่งเป็นโปรเจ็กต์ขนาดเล็ก โค้ดก็มักจะเล็ก สะอาด และดูแลง่าย
      การทำงานร่วมกันย่อมมีโอเวอร์เฮดติดมาด้วยเสมอ
  • อยากรู้ว่าสามารถเทียบกับ Boa ได้ไหม
    คลังเก็บของ Boa
    • ผลเบนช์มาร์กที่นี่ แสดงให้เห็นว่า สำหรับโปรเจ็กต์ที่ทำคนเดียวแล้ว ความสมบูรณ์ถือว่าน่าทึ่งมาก
      ฟีเจอร์แทบจะใกล้เคียง Boa และในบางเบนช์มาร์กก็เร็วกว่า 2 เท่า
  • สงสัยว่าทำไมโปรเจ็กต์ที่เขียนด้วย Rust ถึงชอบเน้นว่า “เขียนด้วย Rust” กันตลอด
    • เมื่อก่อนก็มีช่วงที่พูดกันว่า “เขียนด้วย Lisp”, “เขียนด้วย Ruby”, “เขียนด้วย JavaScript” เหมือนกัน
      คิดว่าเป็นเรื่องธรรมชาติ
    • Rust มีความหมายในแง่ที่ว่า (ถ้าไม่มี unsafe) มันช่วยป้องกันบั๊กบางประเภทได้ตั้งแต่ต้นทาง
      แต่โปรเจ็กต์นี้เองก็ใช้ unsafe ค่อนข้างมากเหมือนกัน
    • สำหรับคนที่ลงทุนกับ ecosystem ของ Rust ไปแล้ว มันเป็นเหมือนสัญญาณให้ค้นพบโปรเจ็กต์ใหม่
    • Rust เป็นภาษาที่ดี แต่มีแนวโน้มว่านักพัฒนารุ่นใหม่ที่มาจาก JS/TS จะยกย่องมันเกินไป
      คล้าย ๆ ปรากฏการณ์ Blub
    • Rust ทำให้ต้องจัดการทั้งการจองหน่วยความจำและชนิดข้อมูลแบบชัดเจน จึงพัฒนาได้ยากกว่า แต่ก็เลยมีซอฟต์แวร์คุณภาพสูงเยอะ
      สุดท้ายมันก็เป็นองค์ประกอบทางการตลาดอยู่ดี แต่โดยเฉลี่ยแล้วคุณภาพสูงกว่าจริง
  • วลี “Compacting garbage collector, written in very unsafe Rust” ทำเอาขำมาก
    • ไม่เกี่ยวกับประเด็นหลัก แต่คิดถึงพวกcracktro introสมัยก่อน
      ลองนึกภาพว่า Ikari intro เด้งขึ้นมาก่อน OS จะบูต
  • อยากรู้ว่าเมื่อเทียบกับเอนจิน JS ที่มีอยู่เดิมแล้วเป็นอย่างไร
    • ดูการเทียบคร่าว ๆ ได้จาก เบนช์มาร์กของ javascript-zoo
    • เอนจินนี้สามารถฝังลงในโปรแกรม Rust ได้โดยตรง
      เป็น Rust เนทีฟเต็มรูปแบบโดยไม่ต้องลิงก์ C/C++
      สามารถเพิ่มการสคริปต์ JS ลงในเซิร์ฟเวอร์ไบนารีเดี่ยวขนาด 40MB ได้
      การที่มี JS engine บน Rust เกิดขึ้นหลายตัวถือว่าเจ๋งมากจริง ๆ
  • หนึ่งในข้อดีใหญ่ที่สุดของ Rust คือความปลอดภัยของหน่วยความจำ แล้วทำไมถึงยังใช้ GC แบบ unsafe กันล่ะ
    • ใน Rust ยังไม่มี GC ประสิทธิภาพสูง ดังนั้นการใช้ unsafe เพื่อสร้างระบบจัดการหน่วยความจำแบบใหม่จึงสมเหตุสมผล
      ถ้าจำกัดขอบเขตของ unsafe ให้เล็กที่สุดก็ถือว่าโอเค
    • จริง ๆ แล้วแม้แต่ไลบรารีมาตรฐานอย่าง Vec เองก็ยังใช้ unsafe ภายใน
      ประเด็นสำคัญคือทำให้ unsafe ถูกจำกัดอยู่ในขอบเขตเล็ก ๆ และตรวจสอบได้
      การทำ GC ก็เป็นหนึ่งในกรณีพิเศษแบบนั้น
    • แม้แต่ unsafe ของ Rust ก็ไม่ได้เปิดกว้างต่อ undefined behavior แบบ C++
      ถ้าเป็นฉันแล้วจะทำ JS runtime ด้วย Rust ก็คงเริ่มจากเขียนให้ปลอดภัยก่อน แล้วค่อยใช้ unsafe เท่าที่จำเป็น
    • unsafe เป็นเครื่องมือสำหรับให้นักพัฒนาควบคุมเองโดยตรงในส่วนที่คอมไพเลอร์เข้าใจไม่ได้
      ถ้าจะทำ GC ประสิทธิภาพสูง มันก็เป็นส่วนที่เลี่ยงได้ยาก
    • โดยส่วนตัวรู้สึกว่าการเน้นเรื่องความปลอดภัยของหน่วยความจำใน Rust นั้นถูกพูดเกินจริงไปหน่อย
      Rust ก็เป็นเพียงภาษาคำสั่งที่เร็วและดีภาษาหนึ่ง
  • มองไม่เห็นไลเซนส์
    • เป็นความผิดพลาดเอง ตอนนี้เปิดเป็นMIT Licenseแล้ว
    • โดยพื้นฐานแล้ว ฉันยินดีกับแนวทางที่ไม่อนุญาตให้บริษัทยักษ์ใหญ่ใช้งานแบบเอาเปรียบ
  • มีคอมเมนต์ที่เข้าใจผิดเรื่อง “Rust ไม่ใช่ภาษาแบบ garbage collection”
    • Rust ไม่ใช่ภาษา GC โดยจะมีการนับจำนวนอ้างอิงก็ต่อเมื่อใช้ Rc หรือ Arc เท่านั้น