> You cannot use multiple cores directly from the same Node program unless you drop down to C++. Well, someone has to drop down to C++, but it doesn't have to

> You cannot use multiple cores directly from the same Node program unless you drop down to C++. Well, someone has to drop down to C++, but it doesn't have to be me (node webworker-threads). This is the same as in most languages. > you cannot use multiple cores directly from the same Node program unless you drop down to C++. As I said in my comment, threading is primarily a runtime thing, not a language thing. There are javascript runtimes (napa.js, node webworker-threads, nexusjs, browsers) that have threading (even by your restrictive definition that doesn't include threads layered onto child processes like the npm package 'threads' does), just as there are runtimes for e.g. java that do not (and the bulk of the threading support in most other language runtimes is also written in C++ so it seems churlish of you to complain about that in javascript runtimes). Most languages do not need significant changes to their syntax or keywords to support multithreading. Maybe you're comparing node.js specifically (where I think that for a long time there was a belief among the leads that letting the OS manage processes was a better approach - it's been interesting to watch this same argument play out in the rust community) with something like Go which has pleasant primitives for concurrency built in as part of the language. If you are, then to some extent I agree with you - something like goroutines might be really nice in javascript and is arguably better than what the js community has, but I also stand by my runtime/language distinction. Goroutines are not OS threads. You can run go programs with GOMAXPROCS set to 1 without changing the language at all.