Live data from Hacker News

A response to Node.js is cancer - The Diagnosis

joshuakehn.com

31–40 of 57 posts

Re: A response to Node.js is cancer - The Diagnosis

#31
post #24
post #10

I strongly disagree with what Ted wrote, but I really wish he would come out and enter a dialog with the community. There's a thread on the mailing list, twitter, and blog responses floating around now, but no substantial effort by Ted to respond to or even acknowledge the replies he's received.

he's responded here: http://news.ycombinator.com/item?id=3065098 with the same attitude he displayed in his original blog post. Not sure there's much point entering a dialog with him.

When you wrestle with a pig, you both get dirty, but the pig likes it.

Dziuba is the very paradigm of an ill-informed lazy troll. He has made his reputation giving other lazy people reasons to not learn new things.

Re: A response to Node.js is cancer - The Diagnosis

#32

Earlier quoted context omitted.

Just offload it to a child process/worker, or use a job queue. How exactly would you avoid that 500ms block in other platforms?

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

That's not avoiding it. The thread in question will still block for 500ms. The same holds true for a multi-process node app.

Re: A response to Node.js is cancer - The Diagnosis

#33

Earlier quoted context omitted.

Just offload it to a child process/worker, or use a job queue. How exactly would you avoid that 500ms block in other platforms?

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

would you mind giving an example of how you would code it so that that 1 request didn't block the rest?

in a browser I'd go with a setTimeout or setInterval hack to "fork" another thread. is this the same in node?

Re: A response to Node.js is cancer - The Diagnosis

#34

Earlier quoted context omitted.

The platform does it: other requests are handled by other threads or processes (pooled or not), one request is going to consume 500ms and the rest will keep on trucking concurrently. Unless you've gone above the capacities of the machine itself, other requests will be little to not affected.

That's not avoiding it. The thread in question will still block for 500ms. The same holds true for a multi-process node app.

The point is that in a multi-thread architecture, you can still serve requests on the other threads. In a single-process non-blocking IO architecture, blocking CPU calculations will block everyone.

Big deal. Use workers to solve that. End of story.

Re: A response to Node.js is cancer - The Diagnosis

#35
I'm going to defer to exarkun on how Twisted does this: http://twistedmatrix.com/documents/current/web/howto/web-in-... Note that his example doesn't bother to chew CPU, but you could chew CPU if you like, as long as you do it in a thread, and still best Node.

Re: A response to Node.js is cancer - The Diagnosis

#36

He totally misunderstands node's reason for existence, and also why it can be awesome. His preferred infrastructure (once I cut through the swagger) is: Highly-tuned request dispatch --> multiple processing threads (or processes) --> back out to requesting client For certain workloads, e.g. long-polling, pubsub or high-number-of-client workloads, unix dispatch overhead is actually very significant. One cannot instant…

Worth adding that hundreds of lightweight threads is totally doable in Node using node-fibers. For benchmarks, check out the README at http://github.com/olegp/common-node/

Re: A response to Node.js is cancer - The Diagnosis

#38
Not sure whether pointing out the slowness of other languages is a considered argument to make here.

Yes, there are other ways of blocking apart from IO. IO tends to be the main culprit, our web apps are mostly waiting for something. A database connection, a file system, another http request.

By making that asynchronous means we don't waste CPU time waiting. We let those external systems do their thing and when it's done, then the rest of the code runs. The important thing is that the IO isn't the bottleneck in node.js. It can do something else while the IO is doing it's thing.

This means that node.js is better at dealing with IO-laden processes better than the typical gamut of web frameworks.

CPU-bound processes are going to block unless they are performed outside of the main event loop. Dziuba is pointing that out, without offering up the obvious approach.

The approach to dealing with CPU intensive tasks is to delegate it to something that can be asynched out. If your platform of choice is multi-threaded, spin up a thread and run it there.

The node.js way, as I understand it, is to use IO to offload that intensive process somewhere else (at least until web workers is bedded in and ready to use). Since the IO is non-blocking, node.js doesn't consume much resources in waiting around for a response from the server/framework dealing with the CPU intensive activity.

The more I use it the more I see node.js as a pipeline connector between IO resources. Those other IO resources can either be other frameworks, or separate node.js instances that do one small job well. (So an IO process could just be a separate node.js instance that performs a CPU intensive task. In this way it doesn't affect the main request recipient in receiving more incoming requests).

One multi-core server can have a dozen or more instances of node running, each doing their specialised tasks and talking to each other asynchronously via IO.

Sure, it's not beginner level stuff. Even Dzubia himself didn't point out the better approaches to his naive solution - in node.js or any other language. node.js is as bad as every other framework when it comes to naive implementations of recursive algorithms. But offloading the calculation out of the main event loop thought non-blocking IO is a different solution that node.js offers. That's one key differentiator.

It would be interesting to see Dzubia demonstrate the implementation of his concocted problem in the framework / language of choice.

Re: A response to Node.js is cancer - The Diagnosis

#40
The article has a point, but poorly told. The problem is the following. Consider the following workload:

- 1 request to http://server/fiboslow

- 1000 requests to http://servir/fast-response

The point is that node will not process any of those 1000 requests until 1st one is finished, while any multithreaded/multiprocess server will do just fine, and process those 1000 requests in parallel.

It's funny that the same people that criticized Java for its AWT EDT as poorly designed, are not praising the same thing in Node.js ;)

Post reply on HN