3 ms·

I use Ruby ALL the time, and I've never once thought, "I wish this was executing faster". Yes, perhaps it could be more efficient, but I don't use Ruby for spe

I use Ruby ALL the time, and I've never once thought, "I wish this was executing faster". Yes, perhaps it could be more efficient, but I don't use Ruby for speed. The way that I see it, Ruby exchanges execution time for programmer time. Alternatively, If I want something to be fast, I'll spend a few days writing it in C/C++/Assembler, but I'd expect to spend at least an order of magnitude more time writing code.

pmelendez 14y ago
Yeah, but this comparison is with Python and the same is true with Perl or Racket which productivity are pretty similar.
uribs 14y ago
Or you could use something like LuaJit, Node.js, Java or Scala that achieves both goals.
- lucisferre 14y ago
  I'm not really sure how Java achieves both goals in the same way Ruby does.
- the_french 14y ago
  None of those languages are equivalent to ruby. They may be faster but they don't support the same features, syntax etc...
draegtun 14y ago
I'm wondering if the OP is trying to point out that Ruby 2.0 is slower on these benchmarks than 1.9?
coldtea 14y ago
>I use Ruby ALL the time, and I've never once thought, "I wish this was executing faster". That's because you (subconsciously or because of your specific work needs) constrain yourself with problems that don't need the speed. But who says that having a X times faster Ruby is not very desirable? - For one, a cash-strapped startup could deploy RoR instances with fewer boxes, saving a lot of hosting costs. (ASIDE: People compare server costs to the salary of a developer to trivialize them. What they always assume though is that the developer makes a US sized salary (in parts of the world, $500/month IS a nice salary). Or they assume he someone is even paid in the first place (think a ramen startup, a university student deep in debt wanting to launch something on the cheap etc). - Second, people might like to write a game in Ruby, a number-crunching app, a drawing app, etc. Why be constrained by the language and need to employ another for the critical parts? This puts a barrier to a programmer (in code complexity, in having 2 codebases, in time needed to manage memory and such). Barriers mean: you can do fewer interesting stuff than what could be possible. >The way that I see it, Ruby exchanges execution time for programmer time. Sure, by why it has to be that way? Nothing inherent in dynamic languages make it so. Of course they will be slower than C, but they can be 10 or 20 times faster than what they are NOW. Pure V8, Smalltalk VMs, JVM languages etc are consistently much faster than pure (no C delegation) Ruby or Python. Ruby has a lot of room to get much faster.

pmelendez 14y ago

Yeah, but this comparison is with Python and the same is true with Perl or Racket which productivity are pretty similar.

uribs 14y ago

Or you could use something like LuaJit, Node.js, Java or Scala that achieves both goals.

lucisferre 14y ago
I'm not really sure how Java achieves both goals in the same way Ruby does.
the_french 14y ago
None of those languages are equivalent to ruby. They may be faster but they don't support the same features, syntax etc...

draegtun 14y ago

I'm wondering if the OP is trying to point out that Ruby 2.0 is slower on these benchmarks than 1.9?

coldtea 14y ago

>I use Ruby ALL the time, and I've never once thought, "I wish this was executing faster". That's because you (subconsciously or because of your specific work needs) constrain yourself with problems that don't need the speed. But who says that having a X times faster Ruby is not very desirable? - For one, a cash-strapped startup could deploy RoR instances with fewer boxes, saving a lot of hosting costs. (ASIDE: People compare server costs to the salary of a developer to trivialize them. What they always assume though is that the developer makes a US sized salary (in parts of the world, $500/month IS a nice salary). Or they assume he someone is even paid in the first place (think a ramen startup, a university student deep in debt wanting to launch something on the cheap etc). - Second, people might like to write a game in Ruby, a number-crunching app, a drawing app, etc. Why be constrained by the language and need to employ another for the critical parts? This puts a barrier to a programmer (in code complexity, in having 2 codebases, in time needed to manage memory and such). Barriers mean: you can do fewer interesting stuff than what could be possible. >The way that I see it, Ruby exchanges execution time for programmer time. Sure, by why it has to be that way? Nothing inherent in dynamic languages make it so. Of course they will be slower than C, but they can be 10 or 20 times faster than what they are NOW. Pure V8, Smalltalk VMs, JVM languages etc are consistently much faster than pure (no C delegation) Ruby or Python. Ruby has a lot of room to get much faster.