Live data from Hacker News

Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

github.com

11–17 of 17 posts

Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

#11

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)

Whoa! you have quite the profile.

Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

#13
The 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 semantics when a JS runtime crashes.

Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

#15
post #13

The 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…

"is a real architectural win, not just a convenience." AI use spotted

Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

#16
post #7
post #6

1. 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…

All of these replies are AI slop.

Re: Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

#17
post #16
post #7

Earlier 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.

is the response also incorrect?
Post reply on HN