
Node.js vs jRuby vs Java (Nobody cares about your technology) ... - fr0ggerz
https://github.com/nddrylliog/blog/blob/master/nodejs-vs-jruby.md
======
EwanToo
The key piece for me is:

"If you could choose n where your language is n times as slow and you are n
times as productive with this language were both true which value of n would
you choose?"

It's absolutely true - For me, if I can build an app 5 times quicker than
before, and the amount of time involved isn't trivial (i.e. a few hours) then
then development time is vastly more important than the end speed of the code.

Execution speed issues can always be solved - it might need more hardware,
better coding, or even a complete rewrite, but it's fundamentally something
that can be fixed.

That's not to say that your choice of stack and architecture isn't important,
it's just that the language itself is only a small part of that decision, and
most architectures (and most performance requirements) can be achieved in most
languages.

~~~
adgar
This is pretty good advice in an entrepreneurial forum where people are most
interested in quickly prototyping an idea for the web, showing it to people
and finding where to take it and how to change the idea, getting people to
look at it who might throw some cash at it, and so on. You're not concerned
about high performance or even really quality engineering yet, all the "soft"
stuff is way more important.

I'd question its wisdom for engineering-heavy work.

 _Edit:_ Also, it makes a bit more sense to posit this:

 _If you could choose n where your language is n_ orders of magnitude slower
_and you are n times as productive with this language were both true which
value of n would you choose?_

~~~
EwanToo
For engineering-heavy work (I work in telecoms where a fair bit of work goes
into reliability), the choice of language is still pretty low in the
importance compared to other decisions.

The language can make things easier (and quicker) to do things the right way,
but it'll always be possible to do the wrong thing.

------
malkia
What exactly is he talking about? I've read it, but got confused...

I've been console game developer for quite some time, and async stuff has
always been around for us (but not so network oriented for the stuff I was
doing - streaming sound, file I/O, DMA from one cpu to another, etc.)

But If I have to direct it, then precooking your data, so data once loaded
only pointer mixup is needed was the basic to get streaming stuff in a game
(Spiderman-2, Ultimate Spiderman, Spiderman 3).

Then comes stuff like ability to cancel async jobs, and off course start
several at the same time, giving some more info to the underlying code - which
should be done first. I can go on technical details in few pages.

What exactly is he talking about?

~~~
nddrylliog
The whole thing came from "someone responding to node.js fanboys who pretend
Node.js is faster at everything". Turns out his response contained a small,
but ultimately flawed benchmark, which in turn provoked the reaction of other
Node.js people. Some of it happened on Google+ and various blogs.

However, your perspective as a console game developer is highly interesting to
me - care to write a bit more about it?

~~~
voodootikigod
Not quite sure I would call people who question trivial benchmarks "fanboys".
I would call people who post trivial one-sided benchmarks the fanboys,
regardless of the language promoted. IMHO.

------
Andi
He should conclude with even more positive statements about developing and
discussing good ideas in the context of use, not technology. I miss good
discussions about ideas and more abstract concepts that go beyond technical
terms and programming languages. Instead everybody is disrupting with his
latest YA* that we had a thousand times.

*) KV stores, node.js hating or petting, the next big X, iPhools, Fezbook, little boyz anonymous - we are the rulerz of the world - hacking, "old tool" in a "new language" thing

(OK, I am enerved ...)

------
schiptsov
This guy, it seems, still don't realize that there is no silver VM^Wbullet and
never will be, and choosing appropriate tools for each particular task is
still absolutely necessary. ^_^

And that clarity, readability and common idioms of a language matters more
than its runtime, and that 100k of Java or Javascript code is not the same
pile of crap as 100k of Python or Ruby code, assuming that it is not specially
obfuscated. ^_^

Fast prototyping that some stacks (VM+frameworks) provide has no correlation
with real production environments where you must consider a system in terms of
data-flows, content types, separate storage for different types and flows of
data, different levels of caching, and so on.

And, of course, in most cases, serving a content from a file on modern FS with
help of a little C code is much faster end more efficient than serving the
same content with some cool VM involved. ^_^

------
alexwestholm
I thunk his point is - he's wasting his breath talkin about it

