[kaoD]

> C++, Java, Lua, Ur, Go, Ruby and Erlang are all faster than JS

Wrong column. You're looking at languages, but a language does not affect performance: its platform does. E.g., the only Ruby benchmark which is faster than Node is actually JRuby, i.e. Java.

> and especially Ruby is a much nicer language

That's a matter of preference. I don't like Ruby myself (nor most languages encouraging classes as their primary constructs).

You shouldn't evaluate languages, but platforms.

> but its not (yet) a very good general purpose tool

Why? I mean, no tool is a very good general purpose tool, but what makes NodeJS worse as a tool than, say, Ruby?

> I don't want to be the guy who has to maintain that callback hell 5 years from now.

Neither do I. That's why I don't use JavaScript for anything else than a target language. You seem to like ES6, why don't you use it and transpile it to plain JS?

Platforms, not languages.

[dragonwriter]

> You're looking at languages, but a language does not affect performance: its platform does.

Both language and platform affect performance, otherwise JRuby would be the same speed as native Java, which is not the case.

> E.g., the only Ruby benchmark which is faster than Node is actually JRuby, i.e. Java.

Which still means that Ruby (as a language, using the JRuby implementation) can be faster than Node (assuming the benchmark at issue is meaningful at all.)

> That's a matter of preference. Anyways, you shouldn't evaluate languages, but platforms.

Since you actually need to choose languages to use, you absolutely should evaluate them. You should, of course, also evaluate platforms since you need to choose those, too (and part of evaluating languages is evaluating the constraints language choices put on platform choices, and vice versa.)

[kaoD]

> Both language and platform affect performance, otherwise JRuby would be the same speed as native Java, which is not the case.

No. JRuby is the platform, that's why JRuby is not the same speed as native Java.

But CoffeeScript has the same speed as plain JavaScript, because both are running over the same platform (NodeJS) even if they're different languages.

It just happens JRuby can only run a single language (Ruby).

> Which still means that Ruby (as a language, using the JRuby implementation) can be faster than Node (assuming the benchmark at issue is meaningful at all.)

Ruby is neither fast nor slow. Languages don't have speed.

> Since you actually need to choose languages to use, you absolutely should evaluate them.

Of course, but you shouldn't evaluate languages on their speed, because then you're measuring something completely unrelated to the language. You can measure platform speed (and the constraints they put on languages you can choose), not the other way around.

---

So, to sum it up, software engineering is all about compromises. Dismissing NodeJS because it ranks 21st in a benchmark is a bit shortsighted.

Of course Java and C are going to beat JS at speed, but... do you want to deal with Java's interfacing mess? Do you want to deal with C's manual memory management? I certainly don't. Especially for a web app.

[cheepin]

I'd like to disagree. The language specifications provide various limits on the kind of performance you can get, regardless of the platform.

Performancewise, for the record, I find JavaScript to be wholly adequate for writing servers, but to say that the platform is what makes it slow(er) doesn't ring true to me. For example, JavaScript has a few poor design decisions that make implementing performant arrays really hard. Some other interpreted languages get this right, and their performance can be (and usually is) much better in that regard. However, this is kind of splitting hairs since you only care about its performance on whatever environment on which you are running it.

[kaoD]

I see what you mean, but isn't the language still extensible? E.g., browsers have native typed arrays[1] which AFAIK are performant.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...