Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js has jumped the shark

unlimitednovelty.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Node.js has jumped the shark

#91

Post by sreque »

Spyro7 wrote: post #30

Am I the only one that considers all of this ranting about Nodejs to be a little bit strange? I would have never expected a post that was obviously a troll to prompt this much of a reaction on both sides of an issue. That so many of these rants and counter rants made it to the front page of Hacker News is somewhat discouraging. I have been playing around with node for a few months, and I have tried to stay completely…

So I've worked on on an older open source project that does exactly what you suggest. The main loop accepts socket requests using non-blocking IO, figures out how to handle that request, and then forks a child process to handle it appropriately.

This can work great and can scale very nicely, but it also has some major drawbacks compared to other solutions. The whole point of the original post was that single-threaded non-blocking event loops are very fragile. You can easily end up accidentally freezing the entire application.

Other problems with forking event loops include:

- Simple Event loops require you to manually CPS-transform your code. This isn't an issue for a simple request-response cycle, but it quickly turns into spaghetti code for anything more complex. For a college class I once wrote a toy non-blocking P2P client in Python using entirely non-blocking IO, while all the other students chose to use threads. My client was very performant, but the code ended up being FAR more complex than everyone else's solutions for the simple reason that I had to code in CPS the complex multi-step interactions that occur between peers.

- If any of your tasks are not independent and must interact with each other, you have to start dealing with IPC, which can be very difficult to get right without a good message passing library. Even with one, it can still be more complicated than using threads. Clojure's STM, for instance, is useless without a shared memory model.

- Your application is not portable to Windows if you rely on forking.

And these are just some of the problems with using a simple non-blocking event loop to drive your entire application. Throw in the fact that you are using javascript, a very unscalable language never designed to do anything more than provide interactivity in the browser and that has incredibly sparse library support, and you've got lots more problems on top of that. Node.js just isn't as useful as its very enthusiastic proponents claim it to be.

Re: Node.js has jumped the shark

#92

Post by exogen »

jbooth wrote: post #64
Spyro7 wrote: post #30

Am I the only one that considers all of this ranting about Nodejs to be a little bit strange? I would have never expected a post that was obviously a troll to prompt this much of a reaction on both sides of an issue. That so many of these rants and counter rants made it to the front page of Hacker News is somewhat discouraging. I have been playing around with node for a few months, and I have tried to stay completely…

So, I'm not a node.js guy, and nothing against it, but being a server-side guy in general, I'll paraphrase a quote that Zed Shaw paraphrased from Chinese Kung Fu novels: "So the intermediate guy is doing all of these backflips and spinning roundhouse kicks and all that, it's very impressive, you couldn't imagine being in that good control of your body. He decides he's pretty good and spars with a master. The master b…

I think in this case, we have yet to see the master put anyone on their ass. We have non-masters slinging insults and ineffective demonstrations.

Don't typical Python and Ruby deployments also need 8 processes to utilize 8 cores? If I'm not mistaken, this is in fact how Heroku works.

Re: Node.js has jumped the shark

#93

Post by rbranson »

Tichy wrote: post #44
wonnage wrote: post #41

Earlier quoted context omitted.

The whole target of his dissatisfaction is this quote on the Node home page: "Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems." That's bullshit. Evented programming isn't some magical fairy dust. If your request handler takes 500ms to run, you're not going to somehow serve more than two requests per se…

V8 is a lot faster than Ruby, so I'd expect page rendering to be a lot faster with Node than with Ruby (supposing both use good rendering engines). Also it seems a lot easier to "outsource" computationally intensive tasks to other processes with Node than with Rails. With node you can stall the response until you receive a result of the computation (within limits), and use the wait time for other tasks. With Rails if…

That's a limitation of Rails, not Ruby. One could use Node.js in the same manner. Ruby has been doing async I/O in the form of EventMachine longer than Node.js has even existed.

Re: Node.js has jumped the shark

#94

Post by jbooth »

exogen wrote: post #92
jbooth wrote: post #64

Earlier quoted context omitted.

So, I'm not a node.js guy, and nothing against it, but being a server-side guy in general, I'll paraphrase a quote that Zed Shaw paraphrased from Chinese Kung Fu novels: "So the intermediate guy is doing all of these backflips and spinning roundhouse kicks and all that, it's very impressive, you couldn't imagine being in that good control of your body. He decides he's pretty good and spars with a master. The master b…

I think in this case, we have yet to see the master put anyone on their ass. We have non-masters slinging insults and ineffective demonstrations. Don't typical Python and Ruby deployments also need 8 processes to utilize 8 cores? If I'm not mistaken, this is in fact how Heroku works.

As far as I'm aware, they do. GIL means that even using threads, they still need 8 processes to utilize 8 cores.

There are more languages than those 3, though, and if those 3 are the languages that you're considering, evented vs blocking i/o is way beside the point when it comes to performance. A super-simple thread-per-connection program with blocking i/o calls from C or Java will demolish the most sophisticated evented system you could ever design in a scripting language. That was my "barely even moves" vs "spinning roundhouse kick" comparison.

Re: Node.js has jumped the shark

#95

Post by Tichy »

rbranson wrote: post #93
Tichy wrote: post #44

Earlier quoted context omitted.

V8 is a lot faster than Ruby, so I'd expect page rendering to be a lot faster with Node than with Ruby (supposing both use good rendering engines). Also it seems a lot easier to "outsource" computationally intensive tasks to other processes with Node than with Rails. With node you can stall the response until you receive a result of the computation (within limits), and use the wait time for other tasks. With Rails if…

That's a limitation of Rails, not Ruby. One could use Node.js in the same manner. Ruby has been doing async I/O in the form of EventMachine longer than Node.js has even existed.

NodeJS builds on some C async framework, so pretty much every language build on C could go the Node route - but it would be a lot of work. Personally I wish somebody would adapt it for Arc - or maybe not, so that if I ever apply to YC again I can do that for bonus points :-)

EventMachine is OK, I suppose, but I have heard that it has some warts. Are there any good web frameworks that build on EventMachine? Though I suppose the basic Sinatra-Style framework would not be that hard to build...

Re: Node.js has jumped the shark

#96

Post by dap »

jbooth wrote: post #90
Tichy wrote: post #81

Earlier quoted context omitted.

Except that event-driven io is actually the simpler solution compared to threads, isn't it?

Depends. For an application where you have significant CPU work, a simple worker pool (not coded by you), with an accept loop while (s=accept()) { dispatchToWorkerPool(s) } And an application-programmer method handleConnection(s) is pretty darned simple. Just do blocking I/O from your threads and rely on the machine to swap in and out appropriately. For the next level, you can have an evented i/o layer that passes se…

That thread pool isn't actually that simple. How many threads do you use? If you throw 1,000 threads at the problem with a 2MB stack each, that's 2GB of DRAM you've thrown away (instead of 20MB * ncores per Node process) -- DRAM that could be caching filesystem data, for example, which could have a huge impact on overall performance.

With Node, the DRAM and CPU used scales with the number of cores and actual workload. With a thread pool, the DRAM used scales at least with the number of concurrent requests you want to be able to handle, which is often much larger than you can handle simultaneously (because many of them will be blocked much of the time).

Assuming you're not willing to reserve all that memory up front, the algorithm for managing the pool size also has to be able to scale quickly up and down (with low latency, that is) without thrashing.

Re: Node.js has jumped the shark

#97

Post by jshen »

exogen wrote: post #92
jbooth wrote: post #64

Earlier quoted context omitted.

So, I'm not a node.js guy, and nothing against it, but being a server-side guy in general, I'll paraphrase a quote that Zed Shaw paraphrased from Chinese Kung Fu novels: "So the intermediate guy is doing all of these backflips and spinning roundhouse kicks and all that, it's very impressive, you couldn't imagine being in that good control of your body. He decides he's pretty good and spars with a master. The master b…

I think in this case, we have yet to see the master put anyone on their ass. We have non-masters slinging insults and ineffective demonstrations. Don't typical Python and Ruby deployments also need 8 processes to utilize 8 cores? If I'm not mistaken, this is in fact how Heroku works.

No, heroku doesn't work that way, heroku lets you spin up processes and those processes can be threaded. I use JRuby and get one process that can use all cores.

Re: Node.js has jumped the shark

#99

Post by politician »

mcantor wrote: post #62
politician wrote: post #53

Earlier quoted context omitted.

"Jumped the shark" joke comments are the sort of thing HNers vote down.

Is """'"Talking about being down-voted before you voice an unpopular opinion" posts have jumped the shark' is dead!""" the "Considered Harmful"-Killer?

I think that's what happened. I guess my meta joke was misunderstood...

Re: Node.js has jumped the shark

#100

Post by generalk »

skeptical wrote: post #85
jrockway wrote: post #60

Earlier quoted context omitted.

I've seen it from the following communities: PHP, Ruby, Perl, Python, Java, C++, C, C#, Haskell, Emacs, Vim, Common Lisp, and Scheme. People are tribal. Some people are attracted to tribes, become attached without really knowing why, and start having the strong urge to fuck with the other tribes. Apparently this was good for the survival of the human race. Perhaps it's a bug now that we should consciously compensate…

__People are tribal. Some people are attracted to tribes, become attached without really knowing why, and start having the strong urge to fuck with the other tribes. Apparently this was good for the survival of the human race. Perhaps it's a bug now that we should consciously compensate for__ That this tribal behavior occurs among software engineering is a rather disappointing fact. Computers are pretty much the edge…

  > That this tribal behavior occurs among software engineering 
  > is a rather disappointing fact.
It occurs amongst software engineering humans. All humans get this to some degree, it's basic ingroup/outgroup psychology.

We're all humans here. It's nothing to do with "devoted to doing something positive" or "using our brains in more advanced ways." It's just the reality of being an evolved ape, and the lack or presence of this trait doesn't make anyone any better/worse than anyone else.

Post reply on HN