Comment by alayek | Hacker News Reader

Comment by alayek | Hacker News Reader

Parent Full thread

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.

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.

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.

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

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

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 had a how to Python async and I found it a bit confusing compared to js).

It has nothing to do with the language, there were other serverside javascript frameworks before node; they didn't take off (e.g. Narwhal).

Node's success has everything to do with the environment itself in combination with the language. The node runtime, the associated stdlib, and most open source/3rd party modules have been written for a non-blocking runtime from day #1. The same stuff can be achieved in plenty of other languages/stacks (e.g. Python + Twisted), but you have much more work to do validating that every single library you use plays nice with async io, sometimes you have more event loop housekeeping responsibilities, etc...

Node's success has everything to do with the environment itself in combination with the language.

Let's be honest: it is nothing to do with either of those and purely a matter of fashion. In a couple of years at most there will be a new new thing and everything will revert to version 0.1, keeping everyone busy but making no actual progress. Gotta soak up those CPU cycles the hardware people are giving us somehow right? Can't let the users get any of that speed for themselves!

>Let's be honest: it is nothing to do with either of those and purely a matter of fashion.

Let's be honest: if you need "fashion" or "idiocy" etc to explain a trend in tech, you don't have an explanation.

Your explanation wouldn't even explain why it was Node+JS that got to be "in fashion" and not something else from the 20000 options.

Your explanation wouldn't even explain why it was Node+JS that got to be "in fashion" and not something else from the 20000 options

That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know.

We pretend like we're "engineers" or "scientists" but there's nothing objective about what we do...

>That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know.

You mean you can't come up with one. Because for me, which followed the scene for 20+ years, there is a perfect explanation.

which followed the scene for 20+ years

I had a homepage in 1994. I've seen them all come and go. This one's no different.

Mhmmm 1994 here also. Your take is shallow, pointless, and meaningless.

It’s as relevant as saying we don’t write apps in COBOL or Modula2 anymore.

I have no horse in this race; Care to share the perfect explanation?

Look upthread:

https://news.ycombinator.com/item?id=15090542

Your personal lack of imagination and insight doesn’t mean there isn’t a reason (there are several, some extremely obvious).

You have it all backwards. Fashion is the reason you hate it, but before it was fashionable it was not. I get that you're bitter and angry, but you do yourself no service by sticking your head in the sand and willfully ignoring the forces that drive popularity.

I'm frustrated that better stuff doesn't win in the market as well, but I've been a web developer 20 years and Node's appeal was pretty obvious and exactly as the GP states. Without that it would not have gained traction to become fashionable.

After two decades in this industry, I've come to the same conclusion. Developers may use logic in coding, but trend-wise, we're bunch of herds following whatever others are doing. We forget whatever lessons we learned previously whenever something new comes out. It's good to see there are others who see insanity in it as well.

I agree with this. I've seen the same but the core problem is we don't learn from others mistakes: we prefer to rely on our own tool-making skills to demonstrate increased facility while making similar mistakes.

The thing missing in developers that I have decried over and over in this devop/agile movement is that SAs had discipline and an ordered idea and that developers exist to perturb the norm to better effect. The two ideas are not readily reconcilable.

There is a logic to following trends, but it has nothing to do with the problems being solved and everything to do with remaining relevant in the workforce.

And nobody really wanted to do these message passing single threaded event loops in other languages, because they could just learn how to use threads instead.

The real innovation that the Node environment and the Javascript language offered is one of marketing to developers who did not know better. Because there were no I/O paradigms in Javascript, one could be created to support this way of doing things, and there was no competing paradigm that people could point to in Javascript to say "Why would I do this when I could just use threads? It's not that hard."

With that out of the way, the floodgates opened, because once the first few people started adopting it because they did not understand threads, it was only a matter of time when "front end" people adopted it, because they did not know any languages other than Javascript. And thus, the current fad was born.

Even nginx? Nginx is fairly new compared to all the really old C code.

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

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.

Your paradigm is showing.

Notice how this doesn't even mean anything.

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.

Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are

My sides.

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

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!

> I/O is not going to be any faster by having more threads.

That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters.

Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.

As far as I can tell, Node.JS actually does use multiple threads for I/O, both for for networking and filesystem operations. But this implementation detail is not something programmers using it needs to think about.

> I/O is not going to be any faster by having more threads.

the world doesn't revolve around making HTTP servers. Maybe you aren't writing apps that do parallelizable serial computations but please don't generalize.

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

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

Reply on news.ycombinator.com