"While we all know and love JavaScript as a language ..."

I know it but I don't love it. It's basically the only game in town when it comes to client side scripting.

Also, the concurrency model of Node.js does not eliminate concurrency related bugs. It's entirely possible to have race conditions, for example, with single threaded code that uses asynchronous callbacks. I guess a lot of people don't realize that. A real solution is no shared state, like Erlang or Clojure.

My gut feeling is that the Node.js library model (no call is blocking) is eventually going to lead to a mess. As I understand it, any API that can potentially block has to take a callback function. What happens when you realize some API that used to not block now may block (due to some increased functionally, platform changes, etc)? Any code that uses that API, and worse, any non blocking API that uses that API, now has to grow a callback too.

It can be done. The Twisted library has done a similar thing for years already. I just don't think it's a very good model for a general purpose server side language.

All that said, Node.js will probably be successful. The fact that browsers are not entirely broken WRT DOM and Javascript means that there is going to be ever increasing amounts of Javascript code around. It makes sense to re-use that development effort on the server side.

> Servers built with Node.js are typically super fast and can handle thousands, tens of thousands, even hundreds of thousands of concurrent connections — something very difficult to achieve with threaded servers. How can that be?

I've read similar sentiments in a bunch of places but whenever I push any real traffic at the nodejs version of our API server it falls over pretty quickly (even with ulimit increases). What exactly are people doing to handle tens or hundreds of thousands of connections?

Incidentally, if any nodejs gurus are interested we're looking for a remote freelancer to audit our nodejs stuff and help us with a deployment strategy (assuming we can get to the 100s of thousands of connections mark).

AND... around and around the carousel we go.

The threads vs. event loop thing doesn't always pan out to either one being 'better' - who do you think is doing the work when your browser, or Node.js does an async call? They use threads too, and there are certain workloads where it's more efficient to just use multithreading instead of event loop + thread pools. I can't find my references atm b/c I'm traveling, but if you google around you will find numerous case studies in the Java world about threads vs. event loops (the Java world has been wrestling with threads vs. event loops too, for the past DECADE)

Remember as an engineer: spike, profile, benchmark, and determine the best solution for the problem.

Nodemanual.org looks like it could become a good resource, but the cheesy Photoshop-brush grass drives me nuts.

It's the epitome of amateurish design as decoration.