It should be noted that the Python code example runs in 4.038s on PyPy.
Standard Python: 1:07.31 :)
A response to Node.js is cancer - The Diagnosis
11–20 of 57 posts
Re: A response to Node.js is cancer - The Diagnosis
#12He 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 instantiate 500 python threads on most unix boxen without severe doom.
For these workloads, essentially ones where you need to push text around with a minimum amount of stream processing on top of it, node is totally, totally brilliant. It is crazy fast. Magically so, even.
If you think of node as a lightweight turing-complete dispatch engine, you will be happy. If, on the other hand, you believe that fairies and pixie dust mean you can write blocking, bloated javascript code and that node will solve your worries, then you'll be disabused of that dream quickly.
On the other hand, if you started down the road with node, and realized at some point that you needed to refactor some of your slow code, you could do so easily. Doing the reverse (scaling an alternate scripting architecture) is not always so trivial.
Re: A response to Node.js is cancer - The Diagnosis
#13I like node.js, but this post completely misunderstands "Node.js is Cancer". The point of that post isn't that node.js is slow; its point is that node.js does concurrency, but not parallelism; i.e., if your code is CPU-bound, it can only serve one request at a time.
It's a bit extreme to conclude that since Node's built-in HTTP server works this way, that it's "cancer." People still use it because it suits their purposes; there's nothing wrong with that.
AFAIK, nothing's stopping anyone from writing a CGI module for Node. It took years for Python to come up with WSGI and Ruby to come up with Rack. People are fed up with CGI and I don't blame Node's developers for excluding it.
Re: A response to Node.js is cancer - The Diagnosis
#14Is there a reason that these examples are using some sort of deeply nested call stack? Is it just to enforce 'slowness' in the function calls? def fibonacci(n): a,b = 0,1 for i in range(0,n): a,b, = b,a+b return b (cadged from zacharyfox.com) performs far, far better than the nested function calls. I imagine it would in javascript as well. In python at least, all that function calling infrastructure is relatively exp…
It's just a canonical form; it's far easier (IMHO) for a beginner to understand a recursively written Fibonacci number computer than your function.
I hear that. In this case, though the entire blog article was complaints about slowness, or blocking behavior as seen through slowness.
Re: A response to Node.js is cancer - The Diagnosis
#15Is there a reason that these examples are using some sort of deeply nested call stack? Is it just to enforce 'slowness' in the function calls? def fibonacci(n): a,b = 0,1 for i in range(0,n): a,b, = b,a+b return b (cadged from zacharyfox.com) performs far, far better than the nested function calls. I imagine it would in javascript as well. In python at least, all that function calling infrastructure is relatively exp…
> Is it just to enforce 'slowness' in the function calls?
Yes. He was just illustrating a point about blocking on the CPU.
Re: A response to Node.js is cancer - The Diagnosis
#16I think a better response to Ted's argument would have been to rewrite the fibonnaci number generator as a forked-off process with a callback that updates the requesting page on completion.
The thrust of Ted's argument (as I saw it, and completely agree with) is that telling people "inexperienced programmers can create high performance systems" is misleading or dangerous without pointing out that you can easily shoot yourself in the foot of you don't understand what is (and isn't) handled "magically" for you.
Using an algorithm that performs poorly in php or python isn't (necessarily) going to magically perform well in node.js's non blocking execution strategy. Abstracting away blocking network or io calls isn't going to help if you don't know (and notice) that your problem is the O(2^n) algorithm you're using.
Re: A response to Node.js is cancer - The Diagnosis
#17So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU?
Situations where blocking is going to be an issue:
1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here.
2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS amounts of CPU. You want the one person with the crazy demand to feel slow, but everyone else to be unaffected. How often does this happen, exactly?
Most modern web apps spend the majority of their time talking to databases, which in NodeJS is a nonblocking operation. If you need to steamroll your CPU frequently, then perhaps NodeJS is not for you, but I don't think that's a common use case.
Re: A response to Node.js is cancer - The Diagnosis
#18So, this may be a silly question, but what exactly are you doing that's going to use so much freakin' CPU? Situations where blocking is going to be an issue: 1. You have roughly equivalent CPU usage per request, which means that you just have too many requests. Threaded or evented will both get bogged down here. 2. Most requests use a small amount of CPU, but every once in a while a request will require an ENORMOUS a…
I don't think using, say, 500ms worth of CPU is all that unusual of a need. If you try to do that with node.js, everything in your program will be blocked completely for 500ms. It doesn't make node.js useless, or 'cancer', but it is a real limitation.
Re: A response to Node.js is cancer - The Diagnosis
#19To be honest, most of his blog posts seem to be inflammatory in nature with a cute picture at the top. I wouldn't be surprised if Ted wrote it merely to get blog views.
Re: A response to Node.js is cancer - The Diagnosis
#20I had the pleasure of missing Ted's original post. I read it before this one, and it was pretty misinformed. I could write a similar article arguing that assembly is useless because it takes so much code to implement a web server using it.
If your server runs in a single thread AND you do expensive calculations per request, you're doing it wrong. You should be caching results, and you need to either move the processing work to a backend server (written in C or something) or shard the frontend across a lot of cores (multiple processes / webworkers). In any of these configurations, nodejs will work great on the front end.
But, most of Ted's post was needless bile. The argument he made isn't justified by the evidence he gave. Don't bother trying to argue with him, its not worth your time.