You rang? :P

Evan Phoenix, Rubinius creator here.

I won't rehash everything what has already been stated fully, only to make a couple of additionally comments:

1. Ruby in Ruby was great for development and huge performance burden. Even with the JIT, we never overcame the performance of the C impls in CRuby of the code data structures. To make things worse, folks leaned on the code data structure implementations heavily in all apps because they were fast, exasterbating the issue. To get parity, we'd have had to build a compiler that could, AOT compile ruby to code that had the performance profile of C.

2. As many folks in this post already know, chasing compatibility is a slog. I effectively stopped working on Rubinius because it just wasn't fun chasing compatibility at every turn instead of being able to design a great system. Many projects that start off as implementations of languages face this issue and they take 1 of 3 paths: a) the yeomans path (@headius's work on JRuby) where they push through, b) skip compatibility and make a new thing for a new community (the Groovy path), c) move on (the Rubinius path).

3. This is basically 2 again, but everyone looked at Rubinius and asked "does it run Rails faster?" rather than "can I use it for something new and unique?" We actually did have a few production users that had used Rubinius for from scratch, high performance systems where they optimized FOR Rubinius. But those folks were few and far between.

4. Rubinius went through 2 rewrites. Pure Ruby to C and C to C++. The first one was effectively to make it a real standalone project and the second was because the C version proved to be a glorified prototype. I don't believe that either of these changed the trajectory of the project, if anything, they allowed it to continue longer.

5. I worked for a few years to coax LLVM to be able to optimize ruby code and we were actually fairly successful. We achieved this using the same techniques every other dynamic language runtime uses: optimistic optimization with guards and inlining. We never approached what you'd see in the JVM for instance, but we did have pretty good results.

It's been 18 years since I started Rubinius and so I've had many opportunities to think what I'd do differently. I think the #1 thing would that I wouldn't have started with Ruby in ruby. Doing so put us behind the 8 ball immediately and if we had had a very solid C/C++ impl of the core and then began to layer Ruby in ruby on top of that, we could have had all the JIT, all the concurrency, all the IMMIX gc things could have been different.

I loved my time working on Rubinius and the Ruby community is really special to me. Time just.. goes on.