News for hackers. Stuff that matters.
Re:JavaScript is Eating the World by jononor on Thursday August 24, 2017 @10:07AM (#15090201)
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.
Re:JavaScript is Eating the World by vardump on Thursday August 24, 2017 @06:09PM (#15094486)
> 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.

Re:JavaScript is Eating the World by jononor on Thursday August 24, 2017 @06:30PM (#15094620)
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.
Re:JavaScript is Eating the World by jcelerier on Thursday August 24, 2017 @06:48PM (#15094743)
> 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.

Re:JavaScript is Eating the World by fundabulousrIII on Thursday August 24, 2017 @11:01AM (#15090635)
Your paradigm is showing.
Re:JavaScript is Eating the World by coldtea on Thursday August 24, 2017 @11:30AM (#15090893)
Notice how this doesn't even mean anything.
Re:JavaScript is Eating the World by fundabulousrIII on Thursday August 24, 2017 @11:44AM (#15091041)
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.

Re:JavaScript is Eating the World by coldtea on Thursday August 24, 2017 @03:17PM (#15093135)
>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.

Re:JavaScript is Eating the World by fundabulousrIII on Friday August 25, 2017 @11:36AM (#15099201)
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!

Re:JavaScript is Eating the World by atoko on Thursday August 24, 2017 @02:10PM (#15092524)
Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are
Re:JavaScript is Eating the World by fundabulousrIII on Friday August 25, 2017 @12:38PM (#15099839)
My sides.