6 ms·

Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in No

by alayek 9y ago

Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have you group all tasks dependent on that time-consuming task, separately. In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. Node JS has shown over the years that it scales well (maybe not as good as Go or Elixir, but enough for most use-cases). Node also offers lot of great tools, that can be easily added to your project via NPM / Yarn. The Node ecosystem has a solution for virtually any task you might need to do repeatedly in a project. Just to be clear, I am not saying Node or its ecosystem is perfect. There's always room for improvement. What I am saying is that what appears as an obvious flaw, is not really a flaw. The language allows other approaches to solve the problem.

jcelerier 9y ago
> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?
- jononor 9y ago
  I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.
  - fundabulousrIII 9y ago
    Your paradigm is showing.
    - coldtea 9y ago
      Notice how this doesn't even mean anything.
      - fundabulousrIII 9y ago
        Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
        atoko 9y ago
        Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are
        fundabulousrIII 9y ago
        My sides.
        coldtea 9y ago
        >Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy. Well, file systems nobody writes in JS, so that's irrelevant. As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.
        fundabulousrIII 9y ago
        Too literal. It's the file system syscalls translated into node which are the problem. Anytime you have the potential to block you lose the relatively clean event loop and enter libuv which is a thread provider. 'Lightweight logic layer on top of libuv': well if I can design, predicate and tout my language on 'event' orientation but then when it needs to do something else it becomes a thin logic layer over the hosts threading model: that's just a win!
- dboreham 9y ago
  Because Node is just a very thin wrapper around V8 and V8 has a limitation that it isn't re-entrant (can't handle multiple threads without breaking).
- creatonez 9y ago
  >well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ? This is exactly how backend Node.js development is done. The tradeoff is that processes are used instead of threads, which uses more memory but is magnitudes easier to work with than traditional threads where mutable bits of memory are shared. Sure, Rust solves these problems but Node still has a place in the world: it is established, easy to pick up, and can share code with the browser. A decent solution to modern web development complexity.
falcolas 9y ago
Using non-blocking IO is a very old trick. Even nginx does exactly this, and it's written in C. The ability to use non-blocking IO does not make a language unique in any real fashion.
- alayek 9y ago
  I have never claimed that it's unique. In fact, most ideas in tech is just old wine in a new bottle. However, I guess what made it appealing initially, was that it uses a syntax known to a lot of web developers. The callback pattern helped. Although these days, we have been moving away to generators or async-await.
  - falcolas 9y ago
    > a syntax known to a lot of web developers This is the key. And it reflects poorly on them for that. Syntax is the easiest part of a language to learn. The nuances of behavior is the hard part - and those nuances change as you move from the browser to the server; what makes good browser code will not make good server code. In reality they shunned a ton of knowledge and community support to keep a particular (and particularly mediocre) syntax. Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax. Never mind that all of the design patterns change. Never mind that the core libraries they use change. Never mind that they suddenly have to be cognizant of how much CPU time their code takes.
    - flavio81 9y ago
      > Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax (...) This is really true and it's sad, because it leads to more security problems on everyday software.
    - tim333 9y ago
      Beyond the syntax, an event loop is conceptually simple in a way that other models often are not. (For example https://news.ycombinator.com/item?id=11555866 https://news.ycombinator.com/item?id=11555866 had a how to Python async and I found it a bit confusing compared to js).

by alayek 9y ago

jcelerier 9y ago

> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

jononor 9y ago
I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.
- fundabulousrIII 9y ago
  Your paradigm is showing.
  - coldtea 9y ago
    Notice how this doesn't even mean anything.
    - fundabulousrIII 9y ago
      Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
      - atoko 9y ago
        Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are
        fundabulousrIII 9y ago
        My sides.
      - coldtea 9y ago
        >Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy. Well, file systems nobody writes in JS, so that's irrelevant. As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.
        fundabulousrIII 9y ago
        Too literal. It's the file system syscalls translated into node which are the problem. Anytime you have the potential to block you lose the relatively clean event loop and enter libuv which is a thread provider. 'Lightweight logic layer on top of libuv': well if I can design, predicate and tout my language on 'event' orientation but then when it needs to do something else it becomes a thin logic layer over the hosts threading model: that's just a win!
dboreham 9y ago
Because Node is just a very thin wrapper around V8 and V8 has a limitation that it isn't re-entrant (can't handle multiple threads without breaking).
creatonez 9y ago
>well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ? This is exactly how backend Node.js development is done. The tradeoff is that processes are used instead of threads, which uses more memory but is magnitudes easier to work with than traditional threads where mutable bits of memory are shared. Sure, Rust solves these problems but Node still has a place in the world: it is established, easy to pick up, and can share code with the browser. A decent solution to modern web development complexity.

falcolas 9y ago

Using non-blocking IO is a very old trick. Even nginx does exactly this, and it's written in C. The ability to use non-blocking IO does not make a language unique in any real fashion.

alayek 9y ago
I have never claimed that it's unique. In fact, most ideas in tech is just old wine in a new bottle. However, I guess what made it appealing initially, was that it uses a syntax known to a lot of web developers. The callback pattern helped. Although these days, we have been moving away to generators or async-await.
- falcolas 9y ago
  > a syntax known to a lot of web developers This is the key. And it reflects poorly on them for that. Syntax is the easiest part of a language to learn. The nuances of behavior is the hard part - and those nuances change as you move from the browser to the server; what makes good browser code will not make good server code. In reality they shunned a ton of knowledge and community support to keep a particular (and particularly mediocre) syntax. Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax. Never mind that all of the design patterns change. Never mind that the core libraries they use change. Never mind that they suddenly have to be cognizant of how much CPU time their code takes.
  - flavio81 9y ago
    > Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax (...) This is really true and it's sad, because it leads to more security problems on everyday software.
  - tim333 9y ago
    Beyond the syntax, an event loop is conceptually simple in a way that other models often are not. (For example https://news.ycombinator.com/item?id=11555866 https://news.ycombinator.com/item?id=11555866 had a how to Python async and I found it a bit confusing compared to js).