← Back to context

Comment by mythz

14 years ago

What a retarded post from a self-proclaimed smart guy.

First he completely misrepresents the point that Node performs well and scales is because it doesn't Block I/O, i.e. the biggest bottleneck in scaling highly concurrent applications.

It's hard to actually pull out any facts or points to dispute since he sounds like a whinny troll on a rant, hand picking disingenuous examples that are obviously going to trip up event loops, something everyone programming against an event loop already knows. A clearer example would simply be:

     while(1);

And the point is this blocks the server 'by design', i.e. no time is spent context switching between threads.

If for some reason he really needed to calculate high fibonacci numbers on a web server he could simply memoized the fibonacci function, and get back your stellar response speeds (on a 2yo Macbook air):

        function memo(f) {
	  return function (x) {
	      f.memo = f.memo || {};
	      return (x in f.memo)? f.memo[x] : f.memo[x] = f(x);
	  };
	}
	fibonacci = memo(fibonacci);

    ~> time curl http://localhost:1337/
	fib: 165580141
	real	0m0.023s
	user	0m0.009s
	sys	0m0.005s

If he's going to profess CGI scripts are a superior way of doing things, I want to see proofs/benchmarks since nothing he's said makes me take his word on face value - that and his previous posts he shows he's an actual baiting, troll - so I wont be relying his advice anytime soon.

And in his quest to poison JavaScript he choses an code example that no one actually uses, since it can be expressed in the more concise equivalent:

    if (my_var != null) {
      // you idiots put Rasmus Lerdorf to shame
    }

"if (my_var != null)" Throws a reference error if my_var is not defined. By checking the typeof it will short-circuit before throwing the error. It is accepted enough to be the default coffeescript implementation of "?" (the existential operator).

The OPs point wasn't that you couldn't write faster code with non-blocking I/O. His point was that just having non-blocking I/O isn't always going to make things faster. Sure, most applications get lucky and have faster implementations, but it is important to understand what is happening behind the scenes in order to avoid hanging yourself. He thinks the Node.js community has not emphasized that understanding at all and the hype around Node.js is leading to badly written applications.