QuickBEAM：將 JavaScript 作為受監控的 Erlang/OTP 程序運行

背景

QuickBEAM 是一個將 JavaScript 執行環境嵌入 Erlang/OTP 虛擬機（BEAM）的開源專案。它讓開發者能將 JavaScript 程式碼封裝在 OTP 的監督樹中，作為 GenServer 進程運行，並提供與 Elixir 函數互調、發送訊息及存取原生 DOM 的能力。這項工具旨在解決全端開發中 JS 邏輯滲透到後端的問題，提供一個具備容錯機制且能與 Erlang 生態系深度整合的沙盒環境。

社群觀點

在 Hacker News 的討論中，社群對 QuickBEAM 的出現展現了濃厚的好奇心，特別是針對其底層架構與 Erlang 哲學的結合。有開發者認為將 JS 運行在 BEAM 上雖然聽起來有些「邪門」，但其背後的工程實踐卻相當出色，尤其是利用 Zig 語言作為 C 語言與 BEAM 之間的橋樑，這種技術堆疊引起了不小的關注。對於已經累積大量 Node.js 邏輯包的團隊來說，這提供了一條將現有邏輯遷移至 Elixir 環境的新路徑，只要該套件不涉及特定的 Node.js 原生 I/O 或 C++ 擴充元件，就能透過其內建的 TypeScript 工具鏈與 npm 支援直接運行。

針對系統穩定性與資源隔離的討論是另一個焦點。開發者們關心 JS 進程是否能被 BEAM 調度器搶佔，以及記憶體回收機制如何運作。作者對此解釋，雖然 JS 運行在獨立的作業系統執行緒上而非直接受 BEAM 調度器控制，但 QuickBEAM 透過設置中斷處理程序來模擬 BEAM 的「Reductions」機制，在每個 JS 指令邊界檢查執行時長與操作次數，從而防止 JS 程式碼無限期佔用資源。此外，每個執行環境都有獨立的記憶體限制與引用計數垃圾回收機制，這確保了單一 JS 進程的崩潰或記憶體溢出（OOM）不會波及整個 Erlang 系統，充分發揮了 OTP 監督樹的優勢。

安全性與沙盒化也是社群討論的重點。有留言者詢問除了記憶體與執行次數限制外，是否還有更深層的防禦機制，例如未來是否支援 seccomp 等系統調用過濾。目前 QuickBEAM 的設計核心在於資料邊界的隔離，JS 與 Erlang 之間的資料交換不經過 JSON 序列化，而是直接進行值拷貝，這避免了跨語言邊界的共享狀態風險。雖然這是一個相對早期的專案，但其展現出的效能潛力與對 Web API 的原生支援，讓不少開發者期待它能成為 SSR 或處理第三方不可信程式碼的理想選擇。

延伸閱讀

• Yavascript：留言中提到的另一個嘗試在 BEAM 上運行 JS 的早期專案。
• QuickJS-NG：QuickBEAM 底層採用的 JavaScript 引擎分支，支援引用計數與循環檢測。
• Zigler：專案中用於整合 Zig 程式碼與 Elixir 的工具。
• OXC：專案內建用於處理 TypeScript 與 npm 套件打包的 Rust 核心工具。