Live data from Hacker News

Node.js - A Giant Step Backwards

fenn.posterous.com

1–10 of 117 posts

Re: Node.js - A Giant Step Backwards

#2
In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel.

I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed.

The next try was node. I got it running and the performance was fantastic. A couple orders of magnitude faster than the Ruby solution and a tenth of the load on the box. But, all those callbacks just didn't sit right. Finding the source of an exception was a pain and control flow was tricky to get right. So, I started porting to other systems to try to find something better. I tried Java (Akka), EventMachine with/without fibers, and a couple others (not Erlang though).

I could never get anything else close to the performance of Node. They all had the same problems I have with Node (mainly that if something breaks, the entire app just hangs and you never know what happened), but they were way more complicated, _harder_ to debug, and slower.

I have a new appreciation for Node now. And now that I'm much more used to it, it's still difficult to do some of the more crazy async things, but I enjoy it a lot more. It's a bit of work, and you have to architect things carefully to avoid getting indented all the way to the 80-char margin on your editor, but you get a lot for that work.

Re: Node.js - A Giant Step Backwards

#3
post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

Have you tried Haskell? Why haven't you tried Erlang? They're both good choices for writing applications that handle making and receiving thousands of concurrents requests because they have very fast lightweight threads and good exception handling and you don't need to write the kind of code that Node.js forces you to write.

Re: Node.js - A Giant Step Backwards

#4
post #3
post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

Have you tried Haskell? Why haven't you tried Erlang? They're both good choices for writing applications that handle making and receiving thousands of concurrents requests because they have very fast lightweight threads and good exception handling and you don't need to write the kind of code that Node.js forces you to write.

Node is appealing because Javascript is ubiquitous, but I doubt it's harder to learn Erlang than it is to learn to write everything in nested callbacks.

Re: Node.js - A Giant Step Backwards

#6
post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

> In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel.

It's asynchronous, not actually parallel. Only a single CPU core will be used in node.js.

However, waiting asynchronous tasks will let other tasks run meanwhile, which can feel like parallelism.

Re: Node.js - A Giant Step Backwards

#8
post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

> I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed.

I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and thought it might be a viable solution just shows your education has failed you. I am highly biased against Node, I think it is a giant step backwards. Every blog post I have read that says the opposite admits they have no experience in anything else so they just default to Node being good. I only hope Node is a fad.

Re: Node.js - A Giant Step Backwards

#9
post #2

In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…

It sounds like your experience was very similar to mine. Except that I long ago upgraded my 80-char margin to 120 :)

Re: Node.js - A Giant Step Backwards

#10
This is a pretty common pattern for any work you have to do asynchronously, pretty much all libraries should be implementing this for you so the first 3 lines should be all you code

   getSomething("id", function(thething) { 
       // one true code path
   });

   function getSomething(id, callback) {
     var myThing = synchronousCache.get("id:3244");
     if(myThing) { 
         callback(null, myThing);
     } else { 
         async(id, callback);
     }
   }
a minor quibble with language style isnt exactly what I would call "A Giant Step Backwards"
Post reply on HN