Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself.
However the problem is how the language is being used:
Because of this, be very careful of the libraries you use. You will most likely have to read the code to ensure there is some thought behind it.
Then if you are hiring node developers, prepare to receive an avalanche of resumes from people without a degree expecting to learn on the job at your expense while receiving a 6 figure salary.
This makes no sense.
They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague).
The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.
That's not entirely true; there've been fairly good write-ups on particular elements of language semantics for which support inhibits VM performance; for instance, there were particularly good write-ups a while back by the JRuby team (Charles Nutter, specifically, IIRC) on Ruby semantics that are problematic in that respect.
Obviously, that doesn't mean that the level of investment by major firms in the interpreters doesn't have an impact, and Node is definitely riding high on Google's investment in making V8 speedy for Chrome. But language differences do matter.
Repeating myself just for you: I was referring specifically to benchmarking language aspects excluding bindings to native code such as files, networking, processes, etc.
A functional prototype is software that implements its functional requirements (e.g: features) but not its non-functional requirements (maintainability, stability, scalability, performance, configuration, monitoring, security, etc.)
What is "a lot of baloney" is people selling functional prototypes for the price of a finished application, or not knowing the difference.