Right now, JavaScript scales well with a single-threaded event loop. Certainly not as fast as something like Go for async tasks, but enough to power much of the web and be easy to write.<p>Why hasn't anyone abstracted the event loop model to scale across multiple machines or utilize modern processors? Perhaps with something more like an Actor model or Erlang's BEAM?<p>It seems like just getting the JavaScript concurrency model as an abstraction over multicore or multi-machine concurrency would be one of the easiest ways to achieve this. I realize that this is still technically difficult, but programming tends towards "just porting things to JavaScript." I would love to have something like Phoenix framework, just built with JavaScript/TypeScript, and I can scale a back end by bumping size of a machine or scaling horizontally.
First, let's understand what the event model is. The event model allows for a single process to use multiple call stacks. This is an example of concurrency not parallelism.<p>Second, when people talk about multiple threads they are typically talking about SMP, or simultaneous multi-processing. JavaScript already does this. It uses WebWorkers in the browser and clusters in Node. Each of those technologies can then coordinate task execution through messaging, such as IPC. Detached-state execution allows for child processes to execute with process independence from the calling process which means killing the calling process will not terminal the child process.<p>Third, when people talk about multiple machine execution they are typically talking about task distribution, which is not the same as decentralization. Distribution is similar to detached-state SMP but reliant upon network access for task distribution and status.<p>You can achieve all this with JavaScript right now. I have done it in a personal application built around decentralization and remote file system management.
I think if you want that, JavaScript isn’t the right tool. The single threaded simplicity is a big part of why it is a useful tool. You can always spin up external processes from within your app, or use a load balancer or queue to share work with multiple identical processes.<p>The idea of just horizontally scaling up a node process wouldn’t make a lot of sense. How would you share scope between the different processes for example? You would need a whole new construct, at which point you’re really throwing away the advantages you had and you should probably be using a different language.
Its a good question. There are worker threads in Node but they seem clunky to use:<p><a href="https://bitsfactory.lilanga.me/posts/nodejs-utilize-multi-core-processors/" rel="nofollow">https://bitsfactory.lilanga.me/posts/nodejs-utilize-multi-co...</a><p>Stateless webservers are easier, since this is merely loaf balancing. Just run more processes:<p><a href="https://stackoverflow.com/questions/2387724/node-js-on-multi-core-machines" rel="nofollow">https://stackoverflow.com/questions/2387724/node-js-on-multi...</a>
If you are talking about nodejs, there is <a href="https://nodejs.org/api/child_process.html" rel="nofollow">https://nodejs.org/api/child_process.html</a><p>Same way that python does parallelism, by relying on the underlying OS to schedule threads and use multiple cores.<p>For JS running in browser, you probably don't want any allowance for such scheduling in the scripts, and let the JS engine in the browser automatically establish parallelism if needed.
I'm not in the node ecosystem, but can't you <i>"just"</i> use node worker-threads for multicore, and run node on multiple machines for multi-machine?<p>If you want the features of BEAM/dist plus running some javascript, I'd suggest you build your coordination layer in a BEAM language and have some glue to run javascript as a spawned port, or possibly connect node as a c_node to dist.
Libuv which powers Node can execute multiple event loops (one per thread).<p><a href="https://docs.libuv.org/en/v1.x/design.html" rel="nofollow">https://docs.libuv.org/en/v1.x/design.html</a><p>You'd need to write your app code in C++ which isn't very popular in web dev.
People used to fork the JavaScript process according to the number of cores present, but it’s less popular now because most infrastructure is provisioned by vCPUs.<p>So people just provisioned for vCPU=1.<p>Node.js (v8) already offloads io tasks to their own threads so it’s already horizontal to some extent.