3 ms·

> Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good m

> Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good model for people who want to write multi-threaded code that doesn't break. This is simply wrong. The "approach" to threading is that there is none. It's single-threaded. You cannot write multi-threaded code directly in JS. On the server side, this can lead to things like a naive fetch after cache miss denying service to your web application. Nothing on the queue can run until the current function call finishes. Even lovely Python doesn't have this issue because, while the GIL is a PITA, Python has real threads, and can switch during a function call. To be clear, I'm not talking about web browser programming, where JS for some time has been the only option. I'm talking about the ridiculousness of server-side JS when we know clock speeds are hitting a wall and that parallelism is the only way to squeeze out more performance. Steele, Armstrong et. al. have lectured at length on this topic. > There are lots of clustering and threading libraries on npm No, there aren't. Running several node processes via PM2 is not threading. You cannot use multiple cores directly from the same Node program unless you drop down to C++. You can vaguely do it in the browser, but the limitations on communications between the main thread and web workers, especially with SharedArrayBuffer being off-limits post-Spectre, are pretty much non-starters. It's a nice option to have for specific cases (games programmers take advantage of web workers to read models without blocking the main thread, for instance), but it's only bolted onto web browsers.

kybernetikos 9y ago
> 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.

kybernetikos 9y ago

> 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.