

Why Rubinius Matters to Ruby's Future - maurycy
http://weblog.raganwald.com/2007/12/why-rubinius-matters-to-rubys-future.html

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

------
tptacek
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
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
Indeed, watch Evan's talk at RubyConf 2007.

<http://rubyconf2007.confreaks.com/d2t1p3_rubinius.html>

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

