Rubinius interview with Evan Phoenix

With all the recent buzz around rubinius, it was serendipitous that
Evan and I had nearly finished an interview. We wrapped it up over
lunch, and it’s posted at:

http://on-ruby.blogspot.com/2006/12/rubinius-interview.html

Happy reading.

pat eyler wrote:

With all the recent buzz around rubinius, it was serendipitous that
Evan and I had nearly finished an interview. We wrapped it up over
lunch, and it’s posted at:

http://on-ruby.blogspot.com/2006/12/rubinius-interview.html

Happy reading.

From the interview:

| Q: What facets of the other alternative Ruby implementations do you
| envy?
|
| A: I envy the jruby developers for not having to debug segfaults,
| thats a biggy.

Then why use C? Why not translate to, say, Eiffel, OCaml, Oberon,
Java, C#? People have written operating system kernels in most of
those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one
could write a language kernel?

Just wondering …

Probably the answer is “I can write C but not Eiffel” (-;

jwm

On 12/7/06, Jörg W Mittag [email protected] wrote:

Just wondering …

Probably the answer is “I can write C but not Eiffel” (-;

At the risk of putting words in Evan’s mouth, one of Rubinius’s goals
is to make the core of Ruby’s runtime accessible to a much, much wider
group of people what we’ve got currently.

Using something less common than C would work against that, even
though personally I’m a big OCaml fan. Rubinius wants to be
mainstream, and the wide availability of C knowledge and C compilers
will assist in that.

Since we’re kinda on the topic of implementation I’ve got a question:

Avi Bryant’s article in response to JoelOnSoftware said you could get
method calls down to a jump and compare.

My impression is that MRI basically uses hashtables for method lookup.

Is it in the cards for Rubinius to receive the sort of optimizations
Avi was talking about? Is it reasonable to expect that an optimized
version of Rubinius could get method calls into the same performance
realm as c# or Java?

This way I suppose C-Extensions would be used more as bridges to
leverage existing libraries, and not for performance reasons.

Any thoughts?

On 12/8/06, Sam S. [email protected] wrote:

realm as c# or Java?

This way I suppose C-Extensions would be used more as bridges to
leverage existing libraries, and not for performance reasons.

Yes. One way to do this is to make the common case as fast as
possible, even if that assumption ‘breaks’ some of the dynamic
features of Ruby. At runtime, you then detect when you’ve violated
that assumption, trap the error, and re-evaluate the code in a slower
mode.

If you pick targets for that that don’t trap very often, you can
supposedly gain back quite a lot of speed. I believe the JVM has
something like this for dynamic invocations, but I haven’t looked at
that code, so I might be making a fool out of myself by saying it.

On 12/7/06, Wilson B. [email protected] wrote:

From the interview:
could write a language kernel?
Using something less common than C would work against that, even
though personally I’m a big OCaml fan. Rubinius wants to be
mainstream, and the wide availability of C knowledge and C compilers
will assist in that.

Arguably, I think Java is more accessible then c, especially as Ruby
gains a wider audience.

  • Rob

On 12/8/06, Wilson B. [email protected] wrote:

Startup time for small scripts is a core requirement for Ruby, and
that’s a problem for the JVM. JRuby is targeting long-running
processes for that reason.
Also, there’s a pretty bad impedance mismatch between the Java opcodes
and what Ruby needs. The JRuby team is working around that by being
really smart and dedicated, but it’s not easy.

Agreed, I didn’t say there weren’t good implementation reasons that
you don’t want to use java.

If you combine the stats for C and C++, it is still the most
widely-used language on Earth. Also, I never want to program in Java
again, if I can avoid it. Heh.

Hm, well obviously I prefer Ruby over Java, but I think I’d take Java
over c or c++ any day if all else is equal. I’ll take NPE’s and
Intellij IDEA over dangling pointers and buffer overruns. :slight_smile:

That said, I’m rooting for rubinius. I saw Evan’s presentation at
rubyconf and I really hope he can rally other core hackers around the
“simpler is better” rallying cry.

  • Rob

On 12/8/06, Rob S. [email protected] wrote:

those (Oberon, Java, C#; not sure about Eiffel, OCaml), surely one

Using something less common than C would work against that, even
though personally I’m a big OCaml fan. Rubinius wants to be
mainstream, and the wide availability of C knowledge and C compilers
will assist in that.

Arguably, I think Java is more accessible then c, especially as Ruby
gains a wider audience.

Startup time for small scripts is a core requirement for Ruby, and
that’s a problem for the JVM. JRuby is targeting long-running
processes for that reason.
Also, there’s a pretty bad impedance mismatch between the Java opcodes
and what Ruby needs. The JRuby team is working around that by being
really smart and dedicated, but it’s not easy.

If you combine the stats for C and C++, it is still the most
widely-used language on Earth. Also, I never want to program in Java
again, if I can avoid it. Heh.

We’re doing Rubinius to make ourselves happier, along with all the other
goals.

On Sat, 2006-12-09 at 06:17 +0900, Rob S. wrote:

If you combine the stats for C and C++, it is still the most
widely-used language on Earth. Also, I never want to program in Java
again, if I can avoid it. Heh.

Hm, well obviously I prefer Ruby over Java, but I think I’d take Java
over c or c++ any day if all else is equal. I’ll take NPE’s and
Intellij IDEA over dangling pointers and buffer overruns. :slight_smile:

Until Java was opened, I’d definitely have chosen C above Java any day.
(and in general, still do.)

Definitely a bit more optimistic for Java than I used to be though.