But if you take that to an extreme, you end up with a hundred tools. I think it's good to have the option to do parallel computing in JS, for those times when it's worth the tradeoff versus having to adopt a completely new language/platform.

Sure, anything taken to an extreme is bad. I wasn't suggesting to do that.

I think if there is a sensible use-case for parallel computing in JS, it would be good to have. However, trying to make a solution before we have a (clear) problem is foolish.

I'm not saying there isn't already a use-case, but I haven't seen one that isn't already covered by languages better suited to solving those problems (e.g. Rust).

Edit to give a different example: parallel computing in JS is like trying to write a web framework in Rust. Sure, you can do it, but Node is already better suited to doing that. At best, you're making a worse version of something that already exists.

> parallel computing in JS is like trying to write a web framework in Rust. Sure, you can do it, but Node is already better suited to doing that. At best, you're making a worse version of something that already exists.

I agree with you, but my point is it's not black and white. For a sufficiently small or simple project, it might make sense to write a web backend in Rust, or do parallel computing in JS, if the cost of learning a new platform outweighs the cost of using the "wrong tool".

In most circumstances, yes, you probably shouldn't use Node.js for parallel computing tasks, just like you shouldn't use C++ for web development, but for some use cases it might be useful. And maybe those use cases don't exist (I don't have much experience in this area, so I don't know), but I just don't like when blanket statements like "use the right tool for the job" dismiss the work other people have done. Surely if Microsoft created this, they have a use case in mind for it?

We have been down this road before. When you have a lot of options "for those times when" you get a lot of abuse. All good frameworks remove choice to prevent a spiraling string of fuckups by people who don't understand what is going on behind their code. For the few of us who do know what is going on it is not a problem but you have to consider all of the code monkeys who are going to be using a given framework without supervision. What would happen if we made everyone program enterprise CRUD applications in C++ from scratch....unmitigated chaos that would lead the business to disavow technology and go back to paper filing cabinets.

You call it "abuse", I call it resourcefulness. I get where you're coming from, but as someone who is not very comfortable with lower-level languages like C++ and Rust, it's great to have the option of whipping together a parallel program in a language/platform I know, rather than having to invest in learning a new one. For longer-term projects, that investment is generally worth it, but I don't think it's useful to be dogmatic about "the right tool for the job".

> What would happen if we made everyone program enterprise CRUD applications in C++ from scratch

I don't think that's a good analogy. A better analogy would be if we started writing everything in JS/Ruby/Python instead of using lower-level languages where performance matters. Except, this is regularly done with great success by many, many companies, so I don't think that helps your point. Sure, you may have to eventually port it to a more performant platform when you hit massive scale, but that point may also never come.

Dealing with threads and shared memory properly is way harder than getting acquainted with modern C++ or Java.

Most cases, when you need to parallelize and multiprocess doesn't cut it, you'll likely need to go to the C++ module route anyway.