A JS runtime kinda like Node but all I/O uses the equivalent of Erlang's drivers (in-process DLLs) or ports (subprocesses using a specific protocol over pipes), or dynamically loaded native modules. New nodes (processes) can be spawned dynamically on the same host.
I've prototyped this sort of thing already with Lua a couple of times, but there are a lot more JS VMs to choose from these days. I have no desire to chase moving targets which don't care about anything but the browser use case. I'm talking about you, SpiderMonkey and V8.
@freakazoid That's similar to the approach "Bare" takes. The core is super minimal and everything is added piece meal via native extensions: https://github.com/holepunchto/bare
@mauve I'll have to check that out!
The advantage of Erlang's ports is that they can't crash the node.
And it occurs to me that too minimal a core can lead to "dependency hell", so even if the system is modular like that, there probably still needs to be a standard way to do I/O securely.
There's also the "ActiveX problem" where as soon as an application wants to do something interesting you lose all protection from the sandbox.
@freakazoid Yeah since it's JS I think the only process isolation will be between workers. Unsure of their overhead but I assume it's high enough you probs don't want more than there are threads.
Regarding the STD they actually have a bunch of modules that you'd want a JS runtime to have, it's just not built into the runtime by default and you pick just the ones you want
@mauve I suppose any JIT is going to have a lot of per-process overhead from the code cache. And you can't share that without the potential for one process to corrupt it and crash or subvert other processes. Maybe one could use a trusted loading/compilation server and a shared code cache that's read-only for the other processes? Could even potentially cache on disk to make up for the context switching and IPC overhead.