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.

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

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.

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

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

My sides.

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.