Running JS on the Beam VM, all written in C. I don't know if this is just cursed, or absolutely brilliant, either way I love it and will be following closely. Will definitely have to play with it.
did you notice that the middleware between C and BEAM is in zig! (disclaimer self promotion)
Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
11–17 of 17 posts
Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#12Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#13Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#14Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#15The no-JSON-boundary piece is the part that stands out to me. Most polyglot runtimes spend a lot of cycles serializing and deserializing at the language boundary, and that cost compounds fast when you are doing SSR or tight per-connection loops. Having Erlang read the native DOM directly without a string rendering step is a real architectural win, not just a convenience. Curious how you handle the supervision semanti…
Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#161. Are each of the JS processes running in its own process and mailbox? (I assume from the description is that each runtime instance is its own process) 2. can the BEAM scheduler pre-empt the JS processes? 3. How is memory garbage collected? Do the JS processes garbage collect for each individual process? 4. Are values within JS immutable? 5. If they are not immutable, are there risk for memory errors? And if there i…
1. Yes. Each runtime is a GenServer (= own process + mailbox). There's also a lighter-weight Context mode where many JS contexts share one OS thread via a ContextPool, but each context still maps 1:1 to a BEAM process. 2. No. JS runs on a dedicated OS thread, outside the BEAM scheduler. But there's an interrupt handler (JS_SetInterruptHandler) that checks a deadline on every JS opcode boundary — pass timeout: 1000 to…
Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes
#17Earlier quoted context omitted.
1. Yes. Each runtime is a GenServer (= own process + mailbox). There's also a lighter-weight Context mode where many JS contexts share one OS thread via a ContextPool, but each context still maps 1:1 to a BEAM process. 2. No. JS runs on a dedicated OS thread, outside the BEAM scheduler. But there's an interrupt handler (JS_SetInterruptHandler) that checks a deadline on every JS opcode boundary — pass timeout: 1000 to…
All of these replies are AI slop.