evan.musing << current

There have been some sad developments within the Engine Yard Rubinius team that I’d like to address head on.

Earlier today, I had the unfortunate task of reducing the team size to 2 people, which meant laying off the rest of the team.

I’m sure this comes as a shock to many, as it did to my friends to whom I had to give walking papers. This was certainly never a scenario that I had ever hoped to find myself in when Engine Yard offered me this dream job early in 2007.

The reason for the layoffs is not Engine Yard divesting interest in Rubinius,
but rather a necessary reorganization of budget priorities. That’s a fancy way of saying that EY could no longer afford to sustain the large team we had.

This is a sad day for me, one that I’ve been dreading. It stings not only
because of what it means to Rubinius but also because of what it means to my friends with whom I will no longer be working. They’ve put blood, sweat, and tears into Rubinius and their everyday presence will be sourly missed. I hope that they do not think badly of me or Engine Yard.

When Engine Yard gave me the go ahead to hire a team, they did it with the best
intention: to help Rubinius grow. And we have definitely done that. In the
last year, we’ve achieved amazing goals within the project:

• We went from running very little ruby code to running rails.
• We got rubygems up and running well.
• We got a parser entirely in ruby integrated.
• We wrote a whole new VM to build on.

We’ve had our fair share of setbacks, but the team has always rallied.

Rubinius will continue to move forward, continually bolstered by the awesome group of people who give up their free time to help on the project.

Tom Mornini has posted on the EY blog as well; you should read his take.

Hi everyone. I’m super happy to announce that we’ve gotten the C++ branch stable enough that we’re making in the default branch. This means that those of you with existing clones are going to likely do a little work to get them sane though.

Here is what was done:

• The old master branch was rename shotgun.
• The cpp branch was copy to the name master.
• The cpp branch was then deleted.

Anyone that has up to now been working on the cpp branch has a couple of options.

1. Delete your clone and re-clone. This is the easiest. The default checkout will be code in the cpp branch and you’re off and going.
2. Fix up your current repo. I did this by doing the following commands:
   1. git checkout master
   2. git reset --hard origin/master
   3. git branch -D cpp

   This will get your local master branch repointed and properly checked out. In addition, the old cpp local branch can be deleted.

Hopefully no one experiences much pain due to this change. It’s been a long time coming and I’m really excited.
If you do run into problems, post a comment or stop on by IRC and we’ll work it out for ya.

Thanks!

Hey folks, sorry for the quietness here. Thought I’d fill everyone in on the current status of Rubinius.

We (the Rubinius team) have been hard at work on a couple of fronts:

• a new C++ VM: the team has been hard at work getting a new VM up and running back to the level we had the old system at. Our output has slowed to a little bit as the rest of the team has gotten up to speed on this new code base. Now, I’m sure you’re wondering why we’ve begun working on a new VM. Well, there are a few reasons:
  
  • Better organized. We’ve learned a lot in the building of the last VM about how to structure things. For instance, using C++ lets us model Ruby classes as C++ classes, providing the VM with the same familiar structure and execution as their Ruby counterparts. This lowers the barrier for understanding and using the code base.
  • Better tested. The old VM, I’m ashamed to say, had no unit tests. From day one of the new VM, we’ve been writing unit and integration tests. This has helped us a lot to keep the code base under control, as everyone who writes unit tests knows.
  • More potential. One of the big changes is keep a lot of parts of the system open. For example, we’re actively experimenting with using LLVM to speed up method execution a lot. The old code base, with no tests, was quite tangled and sadly didn’t provide any easy way forward for a lot of experiments we wanted to do
• We’ve been working a lot of Ryan Davis’s ruby_parser project lately. We’re actively looking to use that code base as Rubinius’ internal parser. This is towards our goal of more Ruby code, but as anyone who’s written a parser will tell ya, it can be a real pain.
  Ryan has made great progress getting it working and integrating it with Rubinius’ Compiler.
• Conferences: Wilson Bilkovich was just in Berlin, talking technical about Rubinius at RailsConf Europe. I’m here in Austin, at Lone Star Ruby Conf, finishing up my keynote that I’ll be giving later today.
  The whole team will be at RubyConf in November as well, and a few are likely going to OOPSLA as well.

I know that a lot of people are eagerly anticipating Rubinius, and I want to thank you all for your patience with me and the rest of the team.

This is a dream project, and turns out to be pretty darn hard and a lot of work. I’ve made the mistake in the past about talking about when I think that we’ll release 1.0. Something I don’t think I properly understood a year ago was the level that people are looking for a 1.0 to operate at. If we released a 1.0 that was 10x slower than MRI, we’d probably be in pretty tough shape.

At the some time, I know people want to play with Rubinius. We fell off doing monthly releases a while back, and we’re going to start getting back on that soon. Hopefully that will give people insight into the project’s progress more.

Again, thanks to Engine Yard and everyone else for wonderful support.

Hi everyone. Been too long since the last update, so wanted to get everyone up to speed.

Rubinius

Things have been a little quiet on the Rubinius front, as I’m sure a lot of you have noticed. We’re still hard at work, currently getting the new C++ VM into shape.
This new C++ VM fixes a lot of fundamental problems the shotgun VM had (type safety, expression ordering, etc), which is a major reason we’re migrating our work to it.

Things have been a little quieter, commit wise, as the rest of the team gets up to speed on the new VM that I’ve been working on. Shotgun has been put into maintenance mode, with updates to the current main coming mainly in the form of bug fixes to the kernel.

I know that the advances we’re making in the new VM everyone will love, from more performance to less crashes to better code organization.

Comic-Con

I’ve just returned from Comic-Con, having spend 4 days in the sun down in San Diego with the rest of nerdom.
It was quite a fun con though quite tiring. We managed to get into some good panels, but didn’t make it into the Hero’s and Lost panels. Seems you had to arrive at 6am to even attempt to get a seat. The line to get in was literally a mile long (no really, I’m not kidding.)

Conferences

Since we’ve been hard at work trying to get Rubinius to 1.0, I haven’t done too many conferences this summer. The next one I’ll be at is Lone Star Ruby Conf down in Austin. Should be fun, I’ve never been to Austin before and people seem to like the city.

I’m super proud to say that we’ve release version 0.9.0. It’s a snapshot of the work we’ve already been doing, but we’re trying to formalize our releases a bit more.

We’re going to be doing another release, 0.10, next month, as well. We’re working to do more releases, more often.

Download it now!

A heads up that I’ll be participating in the RailsConf Community CodeDrive, hacking on Rubinius

Come hang out with me and other project hackers and share the love!

Bring your questions, quandaries, criticisms, and code!

See you Thursday morning at 10am!

We hit a major milestone tonight. As most people know, we’ve been working to run Rails on Rubinius by RailsConf to have something to show off, even if it’s pretty slow.

Well, I’m super proud to say that tonight, rails served up both static and dynamic pages under Rubinius. Previous to tonight, we’d been blocked just trying to get Rails to even load. I decided to just try loading it up and bang on it enough to get it up and going.

In a scary way, it didn’t take very much code. Which meant we were very close already.

It’s pretty late, so I’m going to keep this short. Big thanks to everyone who’s contributed to Rubinius and had faith in us. Enormous thanks to Engine Yard, without whom I don’t know if we’d been able to reach this amazing height.

More updates to come…

I’ve like to formally welcome the maglev development team over at Gemstone to the Ruby environment club.

For those of you that haven’t yet heard of maglev, it’s a brand new Ruby VM being developed by the folks over at Gemstone. Gemstone is the makers of probably the most advanced object-oriented database used today, and have traditionally been a Smalltalk shop till recently.
With the tide rising on Ruby, I’m happy to see another player enter the field. This only means that Ruby is continuing to mature and see that the community is healthy.

I was personally excited to read an interview with Bob Walker and Avi Bryant concerning maglev, because Rubinius is mentioned more than a few times. They’re looking at Rubinius for a couple of reasons. For one, the RubySpec suite we’ve developing and are about to spin off. The more people that we see using the suite and depending on it, the more mature it will become. Not having a spec for Ruby is commonly touted as a reason that it’s a toy, immature language, and anything we can do to dispel that thinking is good for the community.

The other reason that I’m excited about maglev is that they’re taking a very similar approach to the problem of building a Ruby environment. Like Rubinius, the VM is minimal and most of the kernel is implemented in Ruby.
My hope is that the kernel of Rubinius can be refactored and developed to be generic enough for other environments to use. While I know little about maglev’s current environment, they’re a natural build off the work in the Rubinius kernel. I’d hate to see people develop the code functionality of a ruby environment yet again (I count 5 code bases to this effect currently: MRI, JRuby, Ruby.NET, IronRuby, and Rubinius).

Being able to use a generic Ruby kernel is not unique to a smalltalk style VM. With some luck, it could be used by the folks in other environments as well. In my eyes, this is a big win for everyone. For one, this would mean a common code base that consists of the primary Ruby functionality, and thus would mean a vastly reduced worry of fragmentation. Plus it would alleviate the need for this code to be written again, letting future environment developers focus on taking Ruby to the next level in terms of platform integration, performance, etc.

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!