A colleague raised an interesting question which I will paraphrase -- given the desire to build a project that exposes webservices from the ground up, what language would you choose?
My first response was, it depends on the platform. If you are using Azure, for instance, C# is the first class candidate, Node and other languages are tier 2/3. EC2, sky is the limit. Heroku, probably start with Ruby. If all things were equal, I would personally choose Python over Javascript.
Python and Twisted give a lot of the same benefits as Node in terms of async development. Python is more consistent and has a more mature (and featureful) standard library. Node and modules are plentiful, but a lot (even socket.io) still show some signs of being young.
For me, the choice is - right tool for the platform, group, and project you are working on. Personally, I will err towards the more mature when you are talking about scripting languages. (PHP doesn't count, it's super easy and I've used it a lot, but I always feel dirty afterward :) )
You are comparing a language that is like 2 years old vs languages that are pushing 20 years old.
the language doesn't have the cleanest history in terms of design
It is certainly no worse than several of the languages you just listed.
Personally, I will err towards the more mature when you are talking about scripting languages.
Psssst, JavaScript is a year older than PHP.
Sublime JSHint JSFormat (or fixjsstyle)
To get code to some basis of style consistency.
Debugging -
node-inspector or console.log
In the last six months, node-inspector has gotten a lot better, but a lot of times inserting console.log is just faster (mmm...printfs).
Btw I prefer console.error :)
And because when you bolt everything back on to node to get a decent webdev environment it's really not that fast.
And because callbacks are a really shitty way to write async code.
Like most things node is a tool with a very specific use case, as is typical with anything that is particularly fast at one task people assume that it's fast at all tasks. (C anyone?)
And also because unless you are running a free service your code really has to be absymally slow to not make money. Therefore you should program in the environment that is most pleasurable rather than the environment that is 'fastest', whatever that means.
But mostly because most of the people who talk about how great node is really don't have a clue what it actually excels at. Basically, for all the same reasons people hate PHP.
The traditional complaints of javascript were summarized well by Crockford http://www.crockford.com/javascript/javascript.html Most of the people writing in JavaScript are not programmers. They lack the training and discipline to write good programs. JavaScript has so much expressive power that they are able to do useful things in it, anyway. This has given JavaScript a reputation of being strictly for the amateurs, that it is not suitable for professional programming. This is simply not the case. reply
Node the community is still young, but growing. On two recent projects, I tried two different http auth related modules (digest auth). Both had been active for awhile and recently updated (within a month or two). Yet, despite digest auth being pretty established/spec'd out, had some serious flaws (I didn't have the time to offer back feedback, but it is on my list to submit patches). Friends have mentioned similar, though more complicated issues w/ socket.io for production use, one of THE modules used to highlight Node.
Node, JS, and the node environment have their warts, just approach them knowing that. Don't advocate them as awesome rockstar tech.
* Javascript : don't like it. This "[3,1,10,2,].sort()= [ 1, 10, 2, 3 ]" is broken. Don't care about the historical explanations or philosophical arguments about strong or weak typing. It's broken and that's that.
* Nested callbacks. I don't like that. I like green threads and/or processes for handling concurrency. I'll take Go, Scala, Rust, or Erlang's (processes|channels|actors) instead, if not I'll take any green threads.
* Single threaded : server sits there with 16 cores, it's nicer to use something that can automatically scale across them. This also means if any deeply nested callback functions ends up blocking the whole node process stops.
Not trying to upset anyone at Joyent or others who put effort into, just my personal preferences. It is not that Node is bad, it's pretty good, it is just that I don't see a reason to use when they are much better tools out there.
But I think it comes down to people who hate JS lamenting it escaping from client side into the server side.