Not sure whether pointing out the slowness of other languages is a considered argument to make here.
Yes, there are other ways of blocking apart from IO. IO tends to be the main culprit, our web apps are mostly waiting for something. A database connection, a file system, another http request.
By making that asynchronous means we don't waste CPU time waiting. We let those external systems do their thing and when it's done, then the rest of the code runs. The important thing is that the IO isn't the bottleneck in node.js. It can do something else while the IO is doing it's thing.
This means that node.js is better at dealing with IO-laden processes better than the typical gamut of web frameworks.
CPU-bound processes are going to block unless they are performed outside of the main event loop. Dziuba is pointing that out, without offering up the obvious approach.
The approach to dealing with CPU intensive tasks is to delegate it to something that can be asynched out. If your platform of choice is multi-threaded, spin up a thread and run it there.
The node.js way, as I understand it, is to use IO to offload that intensive process somewhere else (at least until web workers is bedded in and ready to use). Since the IO is non-blocking, node.js doesn't consume much resources in waiting around for a response from the server/framework dealing with the CPU intensive activity.
The more I use it the more I see node.js as a pipeline connector between IO resources. Those other IO resources can either be other frameworks, or separate node.js instances that do one small job well. (So an IO process could just be a separate node.js instance that performs a CPU intensive task. In this way it doesn't affect the main request recipient in receiving more incoming requests).
One multi-core server can have a dozen or more instances of node running, each doing their specialised tasks and talking to each other asynchronously via IO.
Sure, it's not beginner level stuff. Even Dzubia himself didn't point out the better approaches to his naive solution - in node.js or any other language. node.js is as bad as every other framework when it comes to naive implementations of recursive algorithms. But offloading the calculation out of the main event loop thought non-blocking IO is a different solution that node.js offers. That's one key differentiator.
It would be interesting to see Dzubia demonstrate the implementation of his concocted problem in the framework / language of choice.
Yes, there are other ways of blocking apart from IO. IO tends to be the main culprit, our web apps are mostly waiting for something. A database connection, a file system, another http request.
By making that asynchronous means we don't waste CPU time waiting. We let those external systems do their thing and when it's done, then the rest of the code runs. The important thing is that the IO isn't the bottleneck in node.js. It can do something else while the IO is doing it's thing.
This means that node.js is better at dealing with IO-laden processes better than the typical gamut of web frameworks.
CPU-bound processes are going to block unless they are performed outside of the main event loop. Dziuba is pointing that out, without offering up the obvious approach.
The approach to dealing with CPU intensive tasks is to delegate it to something that can be asynched out. If your platform of choice is multi-threaded, spin up a thread and run it there.
The node.js way, as I understand it, is to use IO to offload that intensive process somewhere else (at least until web workers is bedded in and ready to use). Since the IO is non-blocking, node.js doesn't consume much resources in waiting around for a response from the server/framework dealing with the CPU intensive activity.
The more I use it the more I see node.js as a pipeline connector between IO resources. Those other IO resources can either be other frameworks, or separate node.js instances that do one small job well. (So an IO process could just be a separate node.js instance that performs a CPU intensive task. In this way it doesn't affect the main request recipient in receiving more incoming requests).
One multi-core server can have a dozen or more instances of node running, each doing their specialised tasks and talking to each other asynchronously via IO.
Sure, it's not beginner level stuff. Even Dzubia himself didn't point out the better approaches to his naive solution - in node.js or any other language. node.js is as bad as every other framework when it comes to naive implementations of recursive algorithms. But offloading the calculation out of the main event loop thought non-blocking IO is a different solution that node.js offers. That's one key differentiator.
It would be interesting to see Dzubia demonstrate the implementation of his concocted problem in the framework / language of choice.