3 ms·

Why Rubinius Matters to Ruby's Future

17 points by maurycy 19y ago

tptacek 19y ago
This argument seems entirely emotional. Rubinius matters because it "feels more joyful" when you know you can't do better by writing in C? News flash: that's going to be true no matter what VM you host Ruby on.
- raganwald 19y ago
  No, that isn't the argument. The argument is that writing things in C is a barrier to entry, therefore fewer people write libraries in C than in Ruby. therefore, if we have a Ruby implementation written in Ruby, we will see more progress on core libraries and features. That is a statistical argument based on predicting the emotions of a large group of programmers.
  - jamesbritt 19y ago
    Indeed, watch Evan's talk at RubyConf 2007. http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html
simianstyle 19y ago
Why would you ever use Ruby to write another programming language? If I had all the time in the world, and speed was really the only issue - I'd go with assembly.
cduan 19y ago
While I see the value in optimizing a language for these "language-enhancements" such as adding new iterators, I would be concerned about a language architect who sacrificed efficiency in other areas as a result. I'd much rather have blazing-fast each() alone over medium-speed each(), map(), fold(), unfold(), collect(), etc. (Sidenote: isn't it a little unfair to compare the collect() implementation, which uses a for-loop, with a recursive unfold() method? Though I don't doubt that the iterative unfold() version would still be relatively slow.)
- shiro 19y ago
  So the Right Thing is a language that allows to extend by itself, and makes such extensions run blazingly fast as well. It's been done in some languages (like the one with lots of ()'s) and I don't think there's an inherent obstacle for Ruby to do so, though it would take time. I don't think they should sacrifice speed for extensibility now, but it'd be nice to aim at both as long-term goals.

17 points by maurycy 19y ago

This argument seems entirely emotional. Rubinius matters because it "feels more joyful" when you know you can't do better by writing in C? News flash: that's going to be true no matter what VM you host Ruby on.

raganwald 19y ago
No, that isn't the argument. The argument is that writing things in C is a barrier to entry, therefore fewer people write libraries in C than in Ruby. therefore, if we have a Ruby implementation written in Ruby, we will see more progress on core libraries and features. That is a statistical argument based on predicting the emotions of a large group of programmers.
- jamesbritt 19y ago
  Indeed, watch Evan's talk at RubyConf 2007. http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html

simianstyle 19y ago

Why would you ever use Ruby to write another programming language? If I had all the time in the world, and speed was really the only issue - I'd go with assembly.

cduan 19y ago

While I see the value in optimizing a language for these "language-enhancements" such as adding new iterators, I would be concerned about a language architect who sacrificed efficiency in other areas as a result. I'd much rather have blazing-fast each() alone over medium-speed each(), map(), fold(), unfold(), collect(), etc. (Sidenote: isn't it a little unfair to compare the collect() implementation, which uses a for-loop, with a recursive unfold() method? Though I don't doubt that the iterative unfold() version would still be relatively slow.)

shiro 19y ago
So the Right Thing is a language that allows to extend by itself, and makes such extensions run blazingly fast as well. It's been done in some languages (like the one with lots of ()'s) and I don't think there's an inherent obstacle for Ruby to do so, though it would take time. I don't think they should sacrifice speed for extensibility now, but it'd be nice to aim at both as long-term goals.