Hacker News new | past | comments | ask | show | jobs | submit login

JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python.

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:

To say you can write a serious library or server code because you know JavaScript, is the same as saying you can write a paper in cardiology research because you know English.

You will find a lot of people that completely disregard the domain knowledge required to write safe, workable code. While this happens in many languages, JavaScript is the lingua franca for those kind of people.

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.




> As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python.

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.


> 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.


Yeah, since PyPy is V8 fast, LuaJit is faster, and Julia is even faster.


I'm not a PL expert, but Ruby's semantics seem much more complicated than JavaScript's.


Perhaps, but Ruby is are more consistent. There is no implicit conversion, no optional semicolons, no dynamic this, the inheritance chain is not disguised by Java-like syntax, everything is an object (there are no primitives), object construction is always uses the .new method, containers mixin Enumerate for a consistent API across arras, hashes, etc. There's no need for "use strict" or built-in statements like with to ignore. All operations are messages between objects. You can extend the semantics by defining message operation on an object, so that you can use + for more than the builtin classes, where it makes sense to do so.


If you have embedded or extended a scripting language it makes perfect sense.

Repeating myself just for you: I was referring specifically to benchmarking language aspects excluding bindings to native code such as files, networking, processes, etc.

e.g: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Then sure, JavaScript has many implementations, so does Ruby and Python. I was referring to v8 (used by node), CPython and Ruby MRI in particular.


I think a lot of that is baloney. Not all apps require the same degree of rigor. In fact most require quite little. If a library is widely used, that's a pretty good indication it's "safe".


What you describe is a functional prototype not a finished application.

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.


Tror inte det blir brunch på stan på söndag




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: