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.
So people just provisioned for vCPU=1.
Node.js (v8) already offloads io tasks to their own threads so it’s already horizontal to some extent.
I'm not in the node ecosystem, but can't you "just" use node worker-threads for multicore, and run node on multiple machines for multi-machine?
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.
Nobody really uses multithreading for node. I mean I'm some projects do (maybe pnpm?) but the threading support isn't great and the event loop performs well.
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.
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.
Agreed, I realize it would need to be effectively another language, or at least a very different implementation.
This isn't to far off from what new projects like Deno and Bun are doing though, apart from also needing to spread the event loop implementation horizontally
Oh I thought you meant they were working on horizontal scaling.
I think this is very far off from what they are doing. It’s still Javascript, and you can take for granted that it follows the Ecmascript spec even if its runtime is different.
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.
So people just provisioned for vCPU=1.
Node.js (v8) already offloads io tasks to their own threads so it’s already horizontal to some extent.
Its a good question. There are worker threads in Node but they seem clunky to use:
https://bitsfactory.lilanga.me/posts/nodejs-utilize-multi-co...
Stateless webservers are easier, since this is merely loaf balancing. Just run more processes:
https://stackoverflow.com/questions/2387724/node-js-on-multi...
I'm not in the node ecosystem, but can't you "just" use node worker-threads for multicore, and run node on multiple machines for multi-machine?
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.
Nobody really uses multithreading for node. I mean I'm some projects do (maybe pnpm?) but the threading support isn't great and the event loop performs well.
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.
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.
Agreed, I realize it would need to be effectively another language, or at least a very different implementation.
This isn't to far off from what new projects like Deno and Bun are doing though, apart from also needing to spread the event loop implementation horizontally
Can you point me to what you’re talking about in Deno? That’s really interesting.
Deno doesn't implements this differently, it's just an alternative server side run time. It has some better defaults compared to node though
Oh I thought you meant they were working on horizontal scaling. I think this is very far off from what they are doing. It’s still Javascript, and you can take for granted that it follows the Ecmascript spec even if its runtime is different.