3 ms·
JavaScript has incredibly good async APIs (promises, async/await, and the seamless integration between the two). As a result, I'm convinced that software writt
by tgsovlerkhgsel 5y ago
JavaScript has incredibly good async APIs (promises, async/await, and the seamless integration between the two).
As a result, I'm convinced that software written in JS is much more likely to actually perform long-running (IO-bound) tasks in the background/in parallel, simply because it isn't a huge pain to do it.
The actual execution speed matters a lot less at that point.
- invalidname 5y agoYou would think that... But unfortunately this isn't the case. You end up running into the global lock problem where something is stuck deep inside NodeJS and you're at 30% CPU utilization with no idea why. Because everything is async you have no way of understanding what the hell is broken without going into the NodeJS source code and debugging that. Profiling NodeJS is futile because of its async nature. You end up with a lot of noise and no substance. I'm looking forward to project Loom which would bring Java threads into hybrid green/native mode. That would deliver throughput as fast as NodeJS but with the performance of Java and clarity of simpler stack traces.
- tgsovlerkhgsel 5y agoI was thinking more about client/interactive software. For server applications handling many requests in parallel anyways, it's a different story.
- galaxyLogic 5y agoRight, async processing performance is hard to predict, but still it helps to be able to use async/await. This brings to my mind the current logistics crisis in the global trade. Lots of parallel tasks and traffic jams and all of a sudden stores don't have stuff and prices are going up and we don't know when will it be back to normal. That is what Node.js can feel like, because it is hard to understand what tasks execute when and who is waiting for what.