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