4 ms·

"its because they used js" But, this was intentional. As for them implementing threading, I am not sure about the history here. Was it like: "We used JS and kn

by jayajay 10y ago

"its because they used js" But, this was intentional. As for them implementing threading, I am not sure about the history here. Was it like: "We used JS and knew we were going to have a ST environment, but because people wanted MT, we tried..." Or, was it more like: "Let's use js and we'll of course need MT like everything else... oh wait... nvm."?

Matthias247 10y ago
I second that. JS is singlethreaded by intention, and IMHO it's ok that way and the reason why the ecosystem mostly works and async libraries can be reasoned about. There are JS implementations (like Nashorn on JVM) which are multithreaded, and imho they would be a much poorer choice. Once you have callbacks and multithreading in a single system there are dozens of things you need to care about (from which thread will callback be fired, how to synchronize that with the remaining logic, ...) and the complexity grows immensely. I think that's exactly the scenario that the JS inventors wanted to circumvent.
- nrjdhsbsid 10y ago
  Java and c# manage threads+async just fine. You're overestimating the difficulty of using then together. In practice you just add the word async or await and go about things normally like in node. Js is single threaded because it was designed that way, not because it's a good design
  - Matthias247 10y ago
    I disagree. In my experience from seeing lots of code multithreading issues are one of the most common. E.g. in Android or C# GUI frameworks it's a super common error that people try to manipulate GUI elements from a background that just invoked their callback - which is not allowed. The issues there are typically that people without much experience don't even think about from thread an event can be fired - and what you should do if it's another one than the main thread. Even if you know about these problems it's often not clearly documented what the threading model of libraries is. Afaik the JS creators explicitly intended to avoid these issues by using a singlethreaded model.
    - nrjdhsbsid 10y ago
      The most common use case for node is probably as a web framework. At least in this case multithreading doesn't cause issues in c# or java. You just add an async decorator to your methods and it works. You're defending the single threaded model as if multithreading is a problem but it's just a feature. you could choose not to use it if you don't mind the performance penalty, just like async. Node not having multi thread support is definitely a negative.

by jayajay 10y ago

Matthias247 10y ago

I second that. JS is singlethreaded by intention, and IMHO it's ok that way and the reason why the ecosystem mostly works and async libraries can be reasoned about. There are JS implementations (like Nashorn on JVM) which are multithreaded, and imho they would be a much poorer choice. Once you have callbacks and multithreading in a single system there are dozens of things you need to care about (from which thread will callback be fired, how to synchronize that with the remaining logic, ...) and the complexity grows immensely. I think that's exactly the scenario that the JS inventors wanted to circumvent.

nrjdhsbsid 10y ago
Java and c# manage threads+async just fine. You're overestimating the difficulty of using then together. In practice you just add the word async or await and go about things normally like in node. Js is single threaded because it was designed that way, not because it's a good design
- Matthias247 10y ago
  I disagree. In my experience from seeing lots of code multithreading issues are one of the most common. E.g. in Android or C# GUI frameworks it's a super common error that people try to manipulate GUI elements from a background that just invoked their callback - which is not allowed. The issues there are typically that people without much experience don't even think about from thread an event can be fired - and what you should do if it's another one than the main thread. Even if you know about these problems it's often not clearly documented what the threading model of libraries is. Afaik the JS creators explicitly intended to avoid these issues by using a singlethreaded model.
  - nrjdhsbsid 10y ago
    The most common use case for node is probably as a web framework. At least in this case multithreading doesn't cause issues in c# or java. You just add an async decorator to your methods and it works. You're defending the single threaded model as if multithreading is a problem but it's just a feature. you could choose not to use it if you don't mind the performance penalty, just like async. Node not having multi thread support is definitely a negative.