[Rohansi]

That's not really a Node problem but a JavaScript problem. Nothing about it was built to support parallel execution like Go and other languages. That's why they use web workers, separate processes, etc. to make use of more than a single core. But then you'll probably be dependent on JSON serialization to send data between those event loops.

[IX-103]

I'm not a Node dev, but I've done some work with JavaScript on the web. Why are they using JSON to send data between v8 isolates when sendMessage allows sending whole objects (using an implementation defined binary serialization protocol under the hood that is 5-10x faster)?

[Drakim]

The biggest reason is most likely that they don't understand serialization, and simply think that objects are somehow being "sent" from one worker to another, which sounds like a cheap reference operation.

[miroljub]

> That's not really a Node problem but a JavaScript problem.

Nowadays Node is JavaScript. They are the guys driving JavaScript standards and new features for a decade or so. Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ...

[promiseofbeans]

I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server.

Yes, there have been a lot of advances in modern JS for things like atomics and other fun memory stuff, but that's just the natrual progression for a language as popular as JS. The 3 main JS engines are still developed primarily for web browsers, and web developers are the primary audience considered in ES language discussions (although I'll concede that in recent years server runtimes have been considered more and more)

[coldtea]

>I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server.

Clients are 90% still v8, so hardly different than Node.

[jerf]

"Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ..."

In principle perhaps not. In practice it is abundantly clear now from repeated experience that trying to retrofit such things on to a scripting language that has been single-threaded for decades is an extremely difficult and error-prone process that can easily take a decade to reach production quality, if indeed it ever does, and then take another decade or more to become something you can just expect to work, expect to find libraries that use properly, etc.

I don't think it's intrinsic to scripting languages. I think someone could greenfield one and have no more problems with multithreading than any other language. It's trying to put it into something that has been single-threaded for a decade or two already that is very, very hard. And to be honest, given what we've seen from the other languages that have done this, I'd have a very, very, very serious discussion with the dev team as to whether it's actually worth it. Other scripting languages have put a lot of work into this and it is not my perception that the result has been worth the effort.