evan.musing << current

By now, a good deal of you have read Charles breakdown of Ruby implementations.
If you haven’t please go read at least the Rubinius section before reading the rest of this post, as it is largely a response to that.

Now, on to Charles section on Rubinius:

Evan Phoenix’s Rubinius project is an effort to implement Ruby using as much Ruby code as possible. It is not, as professed, “Ruby in Ruby” anymore. Rubinius started out as a 100% Ruby implementation of Ruby that bootstrapped and ran on top of MatzRuby. Over time, though the “Ruby in Ruby” moniker has stuck, Rubinius has become more or less half C and half Ruby. It boasts a stackless bytecode-based VM (compare with Ruby 1.9, which does use the C stack), a “better” generational, compacting garbage collector, and a good bit more Ruby code in the core libraries, making several of the core methods easier to understand, maintain, and implement in the first place.

A little background is in order, to put things straight. Rubinius began as a hobby, back in February of 2006 (Same month I got married, that’s how I recall).
At RubyConf 2006, I gave a presentation on what was then the initial work, which at that point constitute 3 bodies of work.

1. A VM written in ruby, using RubyInline to access some raw operations. More slow that you can imagine.
2. A VM written in C, created by hand translating the ruby code into C. Parts of this work were originally done using a translator program I’d written, which tried to convert the VM in ruby into C mechanically. This proved beyond my skill and time level, thus I felt it was more important to have something running.
3. A kernel of ruby code, implementing 95% of the core library / kernel / class library of 1.8. The terminology for this part has always been fuzzy in the Ruby community. Rubinius calls this the kernel, some call it the standard library, some the class library. It’s the implementations of the builtin classes such as Array, Hash, etc.

It’s plainly true that today, the VM is about 22,000 lines, the kernel 23,000 lines. I’ve never hidden this fact from anyone; in fact I’ve put those numbers directly into presentations. That’s been true for pretty much the entire life of the project in the public. The initial ruby prototype was only even run by me.

I do though believe that it still can claim “Ruby in Ruby”. When I present on Rubinius or am asked about this, the response I give is:
What is Ruby?
The typically response is that Ruby is 3 things:

• A syntax
• An execution model
• A kernel

Again, lets have some context. When I began this project, there was buzz about improving things like String and Array. In 1.8, this requires diving down into C right off the bat. Plus, consider languages such as C++ and Java. Java largely claims to be written in Java, since almost the entire class library is written in Java. This lets it evolve faster, because there is no mismatch between Java user code and the Java class library.
It is this that we typically talk about “Ruby in Ruby”. If I’ve not explained this well enough in person and in type, I take full responsibility for this misunderstanding.
There is the long term goal of having a VM which is mechanically generated from Ruby code, in the same way Squeak’s VM is written. But after that RubyConf 2006, there has been no additional work on this, but there is a very good reason for that.

Rubinius today has around 150 people who have received commit rights. The vast, vast majority of their work has been in the kernel, because this is the largest part of the whole system. And probably 95% of that work has been writing Ruby code. This means that for pretty much all contributers, helping with Rubinius means writing Ruby code. And thus to them, it is Ruby in Ruby.

The promise of Rubinius is pretty large. If it can be made compatible, and made to run fast, it might represent a better Ruby VM than YARV. Because a fair portion of Rubinius is actually implemented in Ruby, being able to run Ruby code fast would mean all code runs faster. And the improved GC would solve some of the scaling issues Ruby 1.8 and Ruby 1.9 will face.

Rubinius also brings some other innovations. The one most likely to see general visibility is Rubinius’s Multiple-VM API. JRuby has supported MVM from the beginning, since a JRuby runtime is “just another Java object”. But Evan has built simple MVM support in Rubinius and put a pretty nice API on it. That API is the one we’re currently looking at improving and making standard for user-land MVM in JRuby and Ruby 1.9. Rubinius has also shown that taking a somewhat more Smalltalk-like approach to Ruby implementation is feasible.

But here be dragons.

In the 1.5 years since Rubinius was officially named and born into the Ruby world, it has not yet met any of these promises. It is not generally faster than Ruby 1.8, though it performs pretty well on some low-level microbenchmarks. It is not implemented in Ruby: the current VM is written in C and the codebase hosts as much C code as it does Ruby code. Evan’s work on a C++ rewrite of the VM will make Rubinius the first C++-based Ruby implementation. It has not reached the Rails singularity yet, though they may achieve it for RailsConf (probably in the same cobbled-together state JRuby did at JavaOne 2006…or maybe a bit better). And the second Rails inflection point–running Rails faster than Ruby 1.8–is still far away.

Charles once again gets my hackles up, thought his points are true. We’ve yet to run rails. We’ve yet to run significant Ruby code faster than 1.8. I am finishing up a C++ rewrite of the VM.

I’ve addressed the Ruby in Ruby phraseology above, so lets move past that.

Performance is improving at a slow, regular pace. This is because of 2 factors:

• VM improvements. Adding more caches, more VM logic to make it’s constructs faster. This happens far more infrequently than:
• Ruby code improvements. This happens quite often, because we have so many people working in the kernel. These kinds of improvements will get us a long way, but not the entire way to 1.8 performance. That’s where VM improvements help.

Again, he brings up the sizes of the VM in comparison to the kernel. This will be the last time I address this in this post. Ruby is a dynamic language, which boasts a very rich, featureful kernel. It’s syntax and constructs allow for short, succinct algorithms.
So while, yes, the kernel is the same number of lines as the VM, it’s not unreasonable to say that it probably constitutes 10x the functionality. This is because the written Ruby code is shorter and easier to understand. That’s the whole point of this project, to make the core of it easier to work on and evolve.

Compatibility is not going to be a problem for Rubinius. They’ve worked very hard from the beginning to match Ruby behavior, even launching a Ruby specification suite project to officially test that behavior using Ruby 1.8 as the standard. I have no doubt Rubinius will be able to run Rails and most other Ruby apps people throw at it. And despite Evan’s frequent cowboy attitude to language compatibility (such as his early refusal to implement left-to-right evaluation ordering, a fatal decision that led to the current VM rework), compatibility is likely to be a simple matter of time and effort, driven by the spec suite and by actual applications, as people start running real code on Rubinius.

A quick personal response to a personal attack. I never once refused to implement left-to-right evaluation ordering, this is a bald faced lie. It’s totally true that Rubinius today is right-to-left, because that was much easier to implement way back in the day when the project began. As we started to work on ActiveRecord, we found that there was code that appear to depend on left-to-right ordering, so I brought it up with matz. And now I’m in the midst of changing it. Truth be told, I should have done my research back when the project started, it would have been easier to fix this then than now.

But I take issue with Charles statement that I’m operating fast and loose with language compatibility. We have an awesome team working on RubySpecs, which will end up being a definitive reference for 1.8 behavior. I will always be the first one to defend their behavior, and get Rubinius implementing it properly.

That’s not to say that Rubinius in the past has made temporary pragmatic decisions in implementation. We absolutely have, and in time those are corrected.
Perhaps Charles mistakes my pragmatism and Montana upbringing for a cowboy attitude.

Performance is going to be a much harder problem for Rubinius. In order for Rubinius to perform well, method invocation must be extremely fast. Not just faster than Ruby 1.8 or Ruby 1.9, but perhaps an order of magnitude faster than the fastest Ruby implementations. The simple reason for this is that with so much of the core classes implemented in Ruby, Rubinius is doing many times more dynamic invocations than any other implementation. If a given String method represents one or two dynamic calls in JRuby or Ruby 1.8, it may represent twenty in Rubinius…and sometimes more. All that dispatch has a severe cost, and on most benchmarks involving heavily Ruby-based classes Rubinius has absolutely dismal performance–even with call-site optimizations that finally pushed JRuby’s performance to Ruby 1.9 levels. A few benchmarks I’ve run from JRuby’s suite must be ratcheted down a couple orders of magnitude to even complete.

He’s absolutely correct. We have a ways to go, but I don’t believe we can’t get there. Others before us have made it work, and I think so shall we.

And the Rubinius team knows this. Over the past few months, more and more core methods have been reimplemented in C as “primitives”, sometimes because they have to be to interact with C-level memory and VM constructs, but frequently for performance reasons. So the “Ruby in Ruby” implementation has evolved away from that ideal rather than towards it, and performance is still not acceptable for most applications. In theory, none of this should be insurmountable. Smalltalk VMs run significantly faster than most Ruby implementations and still implement all or most of the core in Smalltalk. Even the JVM, largely associated with the statically-typed Java language, is essentially an optimized dynamic language VM, and the majority of Java’s core is implemented in Java…often behind interfaces and abstractions that require a good dynamic runtime. But these projects have hundreds of man-years behind them, where Rubinius has only a handful of full-time and part-time enthusiastic Rubyists, most with no experience in implementing high-performance language runtimes. And Evan is still primarily responsible for everything at the VM level.

Of course, it would be folly to suggest that the Rubinius team should focus on performance before compatibility. The “Ruby in Ruby” meme needs to die (seriously!), but other than that Rubinius is an extremely promising implementation of Ruby. Its performance is terrible for most apps, but not all that much worse than JRuby’s performance was when we reached the Rails singularity ourselves. And its design is going to be easier to evolve than comparable C implementations, assuming that people other than Evan learn to really understand the VM core. I believe the promise of Rubinius is certainly great enough to continue the project, even if the perils are going to present some truly epic challenges for Evan and company to overcome.

Thank you for the kind works of encouragement Charles. We’re getting there.
I want to say briefly as well that Charles and I are good friends, I just wanted to clear the air slightly and get everyone on the same page.

The venerable Eric Hodel (drbrain) has whipped the rubinius team into blogging more, so this should be the first of many posts to come.

Development front

We continue to push forward, getting rubinius running everyday ruby code. I continue to use irb under rubinius daily, and it’s proved quite stable.

Though, we’ve begun to hit the standard lib code that is quite tricky. Case in point, mathn.rb. mathn.rb adds some new methods to Fixnum and Bignum, as well as redefining some very core methods, like, Fixnum#/ (divide). We’re currently working through how to support this, because as is, when mathn redefines that method to start returning Floats, most of the rubinius system goes south. Thats because the kernel currently assumes that if it uses Fixnum#/, a Fixnum is returned, and it can pass that to other primitives and such.
We’re still unsure about the long term solution for this, but it does bring up a problem with having a very open, dynamic language, where the kernel of the language uses that same open, dynamic runtime. A user can change the behavior of a core, system method, and effect a lot more than they could in MRI. This is the famous double edged sword.
My hope is that we’re able to code the kernel a little defensively and really stabilize the kernel to the point that these kinds of changes wont cause the whole system to go south.

Conference front

Seems that 2008 is going to be the year of conferences for me.

• On Feb 8th and 9th, Ezra and I will be at acts_as_conference, giving a charity tutorial talk about how to be a better ruby developer.
• Next, I’ve been invited to give at talk about rubinius, as well as the “Party” keynote (not sure what the party part is actually) at RubyFools over in Copenhagen, Denmark. This should be a lot of fun for a few reasons.
  1. I’ll be giving a non-Rubinius specific talk for once (the keynote), which is something I’ve wanted to do for a while.
  2. I’ve never been to Denmark, so it’s always fun to visit a new city.
  3. Abby is coming too! She’s going to sightsee and such while I’m at the conference, and we’ll have a few days before and after to take day trips and such. She loves europe, it should be a great time.
• There a bunch after this, but I’m not yet sure which I’m going to. The total is something like 5 or 6 before June 1st, so it’s going to be busy busy busy no matter what.

More to come!

Brian, Wilson, Ryan, Eric, myself, and a rotating cast of dozens are having the first of many Rubinius sprints here in beautiful San Francisco.

In addition to getting all kinds of great code done, we’ve been filling out a lot of paperwork, because I’m proud to official announce that Ryan Davis and Eric Hodel are now officially EY employees, working on Rubinius!!!
This has been a few months in the works, and I’m thrilled that it was worked out as well as it has. Eric has been working hard on getting rubygems running, while Ryan has continue to plug along on his new ruby parser. I can’t say enough about the skills that these guys bring to the project.

In addition to Ryan and Eric, Wilson Bilkovich and Brian Ford will be starting with EY to be paid to work on Rubinius in the January. Again, I’m so amazed and thrilled that EY is providing Rubinius with the funds to let these guys work on a project they love fulltime.

More to come on the details of the sprint. We’re deep into day 3 and getting a lot done.

I’ve arrived back in Los Angeles after another amazing RubyConf. Everything that people say about the conference is true, it’s really a wonderful atmosphere and I enjoyed every minute. Tons of great talks and it’s so much fun to see all the fun ruby people all at the same time.

We (Wilson, Brian, and myself) didn’t get a lot of rubinius code written, but thats OK. We discussed our next steps and gave a lot of demos to people interested in the project.

Off hand, I’d guess that 6 or 7 patches were submitted by people at RubyConf (drnic, Tom Macklin, and I’m sure more), which is awesome. Last year, it took a week or so before people began contacting me about getting into the project. My hope is that that happens again this year.

I know I’ve said it before, but I have to say it again. I’m so happy with the momentum of the project and the community response. It means to me that the project will be a success because there is enough will and brain power behind it to get it over any potential barriers.

Well, thanks to everyone for the generous praise on the talk and the project.

I’m trying to get back on the blog wagon, so I’m going to try and do more, shorter posts.

Anyways, the rubinius team is preparing for the preview release at rubyconf. We haven’t altered the development flow much, though I’m pushing people to get close their tickets for the release.

We moved over to using lighthouse for project track which is working out better for tracking the tickets, especially milestone wise.

At rubyconf, we’ll probably do some sanity checks on the git edge and then just cut a release directly from that. The stability is getting a lot better everyday, something I’m really happy with.

One reason I know it’s getting more stable is that I decided last week to totally start over on the rubinius compiler (the thing that converts ruby text into bytecode). I’ve totally reworked the architecture to be a lot more modular, faster, and much easier to test. I’ve been doing the development of this new compiler solely in rubinius (the original compiler was first built in MRI, like any good bootstrapped system). So far, I haven’t hit any bugs in rubinius while writing and testing compiler2. This fact makes me all warm and fuzzy inside.

See everyone at RubyConf!

The project is getting more and more visible, so I feel it’s important that people have an accurate assessment of where we are. Most of us have seen these old benchmarks, so lets see some more recent results.

I’ve only done rubinius versus MRI. This was performed running on my Powerbook G4 1.67Ghz laptop. I’ll run these again soon on a big beefy server so we can all compare and contrast.

Data

                Test                  MRI             Rubinius
    bm_app_answer.rb             4.727393             0.619218
 bm_app_factorial.rb             1.703541             1.268409
       bm_app_fib.rb            18.739502             5.309634
bm_app_mandelbrot.rb            11.175115                Error
 bm_app_pentomino.rb              Timeout              Timeout
     bm_app_raise.rb             6.825073             5.744597
 bm_app_strconcat.rb              4.46694             4.086749
       bm_app_tak.rb            24.502033             7.291604
     bm_app_tarai.rb            21.071624            11.594766
    bm_loop_times.rb            16.028508              Timeout
bm_loop_whileloop.rb            29.844976             4.767554
bm_loop_whileloop2.rb            5.232881             1.103926
  bm_so_ackermann.rb              Timeout             6.626395
      bm_so_array.rb            18.276808              Timeout
bm_so_concatenate.rb             5.597246              Timeout
bm_so_count_words.rb             0.099502                Error
  bm_so_exception.rb             9.262875             7.553756
      bm_so_lists.rb             3.372947              Timeout
     bm_so_matrix.rb             5.605184            23.462452
bm_so_nested_loop.rb            17.162697            54.288111
     bm_so_object.rb            19.170284            21.458258
     bm_so_random.rb             7.168005            24.018174
      bm_so_sieve.rb             4.870225            15.966473
     bm_vm1_block.rb              Timeout              Timeout
     bm_vm1_const.rb            47.509964             11.05456
    bm_vm1_ensure.rb            45.855905             5.395634
    bm_vm1_length.rb            49.408877            24.633311
    bm_vm1_rescue.rb            35.682676             6.107035
bm_vm1_simplereturn.rb          47.935916            15.641316
      bm_vm1_swap.rb              Timeout             8.041324
     bm_vm2_array.rb            18.284155            12.393373
    bm_vm2_method.rb             34.70641            16.282999
bm_vm2_poly_method.rb            45.63907            23.423347
bm_vm2_poly_method_ov.rb        11.462504             6.403511
      bm_vm2_proc.rb            22.432265            27.886953
    bm_vm2_regexp.rb            11.580949              Timeout
      bm_vm2_send.rb            11.223254            21.448888
     bm_vm2_super.rb            12.599854             4.998904
     bm_vm2_unif1.rb            10.726272             3.185878
    bm_vm2_zsuper.rb            14.236729             4.948068
bm_vm3_thread_create_join.rb     0.086081              Timeout

Analysis

There are a few trends in the data I’d like to point out.

• Of tests that did not error or timeout, rubinius was faster in 24 of 31. Wow first off, thats a huge improvement over the previous run.
• The slowest section for bm_so. Rubinius was only faster in 2 of 11, and actually error or timeout on 4. If you look at those benchmarks, you’ll see that they are basically tests of a few core methods, mainly things like String#<<. So it makes sense that at this stage, we’re slower on those. We haven’t yet tuned those at all.
• One big trend is that tests that only stressed the VM architecture came out WAY faster. 2 examples are bm_vm1_swap and bm_vm1_simplereturn. The first swaps two local variables using a, b = b, a a few million times. This is a good example where the bytecode VM is much faster than the tree walker in MRI. Next, bm_vm1_simplereturn shows off rubinius’s ability to create a method context quickly and return to the sender quickly. I’m thrilled about this number because even though rubinius MethodContext’s are first class, they’re still 3 times faster with no programming power loss.

All in all, I’m very happy with these results. They show that the project is advancing and is a viable ruby implementation, not just a toy.

Update: More Data

Here’s the data from running on a 64bit xeon. The rations are not the same because I haven’t yet got direct threading working properly on 64bit platforms, so that impacts rubinius performance negatively in this case.

                Test                  MRI             Rubinius
    bm_app_answer.rb             0.674141             0.357815
 bm_app_factorial.rb                Error              0.40302
       bm_app_fib.rb             6.023813              2.86666
bm_app_mandelbrot.rb             2.305716                Error
 bm_app_pentomino.rb              Timeout              Timeout
     bm_app_raise.rb             1.634094             2.681252
 bm_app_strconcat.rb             1.541677             1.466644
       bm_app_tak.rb             7.749194              4.02251
     bm_app_tarai.rb             6.194152             6.621082
    bm_loop_times.rb             3.520025            32.848938
bm_loop_whileloop.rb             8.091596             2.464447
bm_loop_whileloop2.rb            1.736418             0.609515
  bm_so_ackermann.rb                Error             3.579584
      bm_so_array.rb              4.89737              Timeout
bm_so_concatenate.rb             1.573779              Timeout
bm_so_count_words.rb             0.145074                Error
  bm_so_exception.rb             3.179525             3.461771
      bm_so_lists.rb             1.429547              Timeout
     bm_so_matrix.rb             1.842544            10.748483
bm_so_nested_loop.rb             5.337045            18.885963
     bm_so_object.rb             5.428432             9.856728
     bm_so_random.rb             2.612983            11.789056
      bm_so_sieve.rb             0.711854             5.268267
     bm_vm1_block.rb            26.471025             37.74646
     bm_vm1_const.rb            14.004854             5.930651
    bm_vm1_ensure.rb            14.199208             2.854205
    bm_vm1_length.rb            16.117594            13.692691
    bm_vm1_rescue.rb            11.509271             2.859993
bm_vm1_simplereturn.rb           14.78014             8.154143
      bm_vm1_swap.rb             22.52124             5.419691
     bm_vm2_array.rb             6.238171             4.938015
    bm_vm2_method.rb             9.747336             9.017925
bm_vm2_poly_method.rb           12.513751            11.709814
bm_vm2_poly_method_ov.rb         3.961969             2.150468
      bm_vm2_proc.rb             6.393898            10.224857
    bm_vm2_regexp.rb             3.224304            54.639602
      bm_vm2_send.rb             3.375969            12.034005
     bm_vm2_super.rb             4.012679             2.795978
     bm_vm2_unif1.rb             3.005257             1.716368
    bm_vm2_zsuper.rb             4.336752              2.83723
bm_vm3_thread_create_join.rb     0.14954                Error 

When rubinius switched to git recently, we wanted the ability to keep a read-only svn repo running that had the same changes in it. This would let casual people who don’t wish to use git to at least check out the latest code easily. So with some jiggering, I came up with the follow recipe.

1) Setup tailor

Tailor is a python program with is used to translate changes in one version control system into another. It does this by using the native tools for the systems and working copy of code. When there is a change, it simple updates the working copy from the source, then checks them into the target. It’s basically a brute force way, but works quite well.

I use the following tailor config file for rubinius:

[DEFAULT]
verbose = True

[rbx]
target = svn:target
start-revision = c6f4d90df72b103884fa5470a433f5513d2c524d
root-directory = /home/evan/work/tailor/output
state-file = tailor.state
source = git:source
subdir = .

[git:source]
repository = /var/cache/git/code

[svn:target]
module = /rubinius/trunk
repository = file:///home/evan/work/rbx-git-tailor

• start-revision was about 10 commits back from HEAD at the time I did the import. I did this so I didn’t have to wait for tailor to replay all of the commits in git, but still included the last 10. Moving forward, it does all commits.
• root-directory is the working copy directory tailor uses to pull in and commit changes. Make sure it’s an empty directory.
• /var/cache/git/code is a bare git repo, so be sure that repository points to a bare git. In fact, most people will tell you to only use a bare git repo (not one that also contains a working copy) on servers which you push to. push does not update the working copy and it can get quite confusing otherwise.
• The svn target repository should a path that doesn’t exist. Tailor will create the repo the first time it runs. Do NOT point it at an existing one!

2) Git hook

Next, I used the post-update hook in git to automatically run tailor. Heres my post-update hook currently:

echo ""
echo "Updating http://git.rubini.us/svn for the less git inclined"

lockfile -1 ~/tailor.lock

/usr/bin/tailor -c /home/evan/work/tailor/config > ~/tailor.log

sudo -u evan /bin/kill -USR2 `cat /home/evan/work/matzbot/matzbot.pid` > /dev/null 2>&1 || true

rm -f ~/tailor.lock

exec git-update-server-info

The output of the post-update hook goes to the client doing the push, so the echo’s are for the git developers benefit (they’ll probably wonder why their commit pauses at the end if git is sooooo fast otherwise).

I use the lockfile program so that 2 commits don’t try and run tailor at the same time. I don’t know what would happen and personally don’t want to know. Better safe than sorry.

The kill -USR2 tells an irc bot we run in #rubinius that there are new commits to show people. Thats available in git.

Caveats

I have all my git developers pushing via ssh, all as the git user, ie git clone git@git.rubini.us/code. This means the post-update hook is run as the git user. So while the tailor working copy is in my home directory, I’ve chgrp it to git and run chmod g+r -R so the git user can properly use it.

I have the ouput from running tailor redirected into a file, so I can monitor it. So far, the only problem I’ve had with this is that my git user didn’t have a name in /etc/passwd, so git complained about not being able to properly form the author field.

This is read only. Do NOT let people check directly into the svn repo tailor is updating.

I’ve cut 0.8, another developer preview for people to play with.

It’s available at on rubin.us

Rubinius still very much still a work in progress, so there are a lot of rough corners you’re bound to experience.

A long overdue update about my big project rubinius.

Scheduling

The team is still moving along nicely, still aiming for a 1.0 release by RubyConf 2007. We’ve still got a ways to go, but I’m confident. A part of the team is getting together for a sprint in mid September. Other projects have used sprints to really pull away, productivity wise, and I’m hoping we can do the same.

Git

In the last few days, I decided to migrate the project off Subversion to Git, the DSCM. While I’m certain some will see this as a complete waste of time, I feel that it’s important for the project in the long term, and the developers in the short term.

Long Term

As many people are aware, the mainline ruby interpreter (MRI) suffers a lack of transparency. The perception (I can only speak for rubyists in the US, and perhaps a few in Europe) is that ruby-core team works at their own pace and doesn’t accept much input into the process, nor does it report on the process much.
Now, whether or not you agree with that assessment is not what I’m concerned about. It’s the long term perception and possibility that this same thing could happen to rubinius. So rather than wait and see, I’ve decided that the best way to avert this is to make it as easy as possible to contribute and progress rubinius. Again, some will argue that git was not required to reach this goal, and that is a valid argument. Part of it was just a irrational decision, I’ve been interested in git for a while and wanted to play with it more.

Short Term

Local branches, sane merging, a toolkit interface, oh my! I’ve already fell in love with the parts of git that svn lacks, which in my book, was a reason to switch anway. The tools are richer and more powerful. The code is cleaner. Nuff said.

Application Push

We’re currently in a phase of development I’ve been calling Application Push, which is just a fancy term for try to run shit. The existing body of ruby code is quite dense and provides an excellent proving ground to flesh out rubinius. The project has finally progressed enough that this level of proving can be done. Charles has talked about how this style of dev is what really pushed JRuby to 1.0, so we’re hoping to follow in those same footsteps.

Currently playing in iTunes: The Outernationalist by Thievery Corporation

I’ve uploaded the slides from my recent talk at Silicon Valley Ruby Conf (SVRC). Check them out.