Node.js vs jRuby vs Java (Nobody cares about your technology) ...
1–10 of 15 posts
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#2The 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.
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#3What 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?
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#4The 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…
>>"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?"
>>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.
I would set n somewhere between 50 and 100. Then benchmark the resulting programs and rewrite bottlenecks in C. (Just think about it; years of productivity in a month! Then another few months to optimise the prototype.)
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#5I thunk his point is - he's wasting his breath talkin about it
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#6What 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 streamin…
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?
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#7What 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 streamin…
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?
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.
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#8This 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. ^_^
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#9The 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…
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?
Re: Node.js vs jRuby vs Java (Nobody cares about your technology) ...
#10The 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…
It also depends on how fast the app needs to be, and how far your computer is (e.g. the answer might have been different 20 years ago for the same task) - it would be nice to express the question differently, to make it invariant of these aspects.
For "interesting" tasks (in a research sense), speed is limited by combinatorial explosion. Finding an algorithm/approximation/heuristic that avoids or reduces that is the only real solution - because faster languages, like faster computers, can only give you linear speed up.