You may also download this file. Running time: 00:25:37
In this interview with O'Reilly, Chad and Rich discuss where Ruby and Rails have gone in the past year, whether RESTful composition obviates the need for ORM, what's interesting in the upcoming world of Ruby and Rails, and how Maglev, Rubinius, and other new Ruby implementations contribute to the world of dynamic languages.
RailsConf Europe is coming up shortly and I thought it would be good to give our readers and listeners a sense of what's going on and not just with Rails and Ruby but with the Conference, especially for people who can't make it this year or who might think about making it next year either to the American version or European version. Let me start out by asking what's new in the world of Rails this year. What's interesting?
Chad Fowler: Okay; I guess I'll take that initially. New in the world of Rails--I think the big thing is that there's not a lot new which sounds kind of boring but it kind of means that we're reaching a point that things have matured and stabilized. It used to be kind of a joke that Rails releases would keep coming out and keep breaking things and you kept having to upgrade your apps. Because of the rapid influx of developers in the early stages of Rails due to the superb marketing done by David Heinemeier Hansson, I think we had a larger audience for that phase of Rails' lifecycle than you would normally have in a new technology.
When normally a new Open Source project comes out very few people use it, and then it starts gradually picking up steam. With Rails it was really just this big bang; everyone is using 0.8 or 0.9 and living with the pain of upgrades. Rails 2.0 which came out almost a year ago now--it was late last year--has really stabilized things and the stuff that's really going on in the Rails world is people figuring out how to do Rails right and not just do it like J2EE or do it like PHP. It really has its own style of doing stuff and so it's really kind of a maturing and clamping down and figuring out how to do good Rails development as opposed to just trying to figure out how to do Rails development.
Rich Kilmer: I think another thing that's happened this year and I think it will continue is that the innovators were the main people that were actually using Rails. Up through last year the main folks that were focusing on Rails were the innovators, people that needed to be possibly because they were startups and they needed to move fast, but I think that those that have adopted Rails this year and that are continuing to go forward are what we'd consider more mainstream shops--possibly internal corporate customers and things like that; government. We're out here in Northern Virginia in the DC area, so we hear a lot about what's going on there, and there's a lot of movement in the government to use Open Source technologies and get away from proprietary technologies. There's a lot of interest, and people are using Ruby and Rails to do that, so I think it's starting to kind of mainstream and I think some of the things that Chad is talking about as far as stabilization and learning, that is part of this whole. This is what happens when a framework and language actually becomes used by a broader and more--well, we'll just call it traditional--development community.
One of the things that I remember hearing a lot about especially from DHH last year at Rails Conf in the US was the idea of getting rid of action web service and moving towards a RESTful infrastructure. I haven't heard as much about that this year; is it one of those pieces that Rails programmers more or less take for granted in Rails 2.0 or is that still under development and an option?
Chad Fowler: Yeah; it's actually permeated everything now, so we take for granted is probably a good way to say it, although I think mostly that's still in the leading edge space, but if you generate an application and generate a default scaffolding and all that stuff it just does everything in this Rails REST style, which really is two things. The big design shift is that every application is thought of primarily in terms of CRUD operations on resources, so through CRUD, REST maps to CRUD very cleanly. Basically that is the state of the art and best practice Rails development as much as I hate that term--best practice; that's what people are doing and it's gotten to the point now where if you get on a project and it's not using the REST conventions then people actually look at you funny like well what are you doing here? Is it on purpose or do you just not know what you're doing? It's not really even a decision that people make anymore, which is great because Rails is all about convention over configuration. What this REST stuff did was just add even more conventions that take the boring non-value added decision making out of the process as you're starting to build apps and get you thinking more about actually doing functionality and what the interface would look like and that sort of thing.
Rich Kilmer: It also informs the way you model your domain and I know in the projects we've worked on it's made people think through their domains so that they structure the representation of the domain in kind of RESTful friendly ways. David when he announced they were going to this RESTful thing, he talked about some of those changes to models that were necessary in order to be RESTful, but I think that now it just becomes the norm. It's just kind of the way to do it.
Chad Fowler: what I actually ended up doing is pulling more nouns out of the domain than you would normally find, especially in experienced software developers would normally found and I found in my own work that makes me do better object-oriented designs to have this kind of straight jacket of trying to make stuff fit the RESTful conventions. Sometimes it doesn't work and that's okay, but what it did is it took a bunch of developers that would have otherwise potentially not thought really closely about how they were modeling their objects and made them have to give a lot of thought to well what is the relationship between these two entities and what should it be called? Normally you would just connect them with a join table and in the REST world it's not like that. Anything you want to manage via the web you have to have a name for and if it has a behavior then you put the behavior and the class that represents that thing. Like Rich said, it really does enhance the way that we're designing our applications.
Within Rails itself, we take REST for granted. What about Rails applications in a larger ecosystem? They expose the four RESTful verbs and all of these nouns, via URIs; are you seeing people take advantage of that through other applications that may speak REST to a Rails application?
Rich Kilmer: Actually we've done several interesting integrations with we'll call it like compositing different technologies into a single unified application. One of them was kind of a layered Rail service where we had a user-facing Rails application and then another Rails application actually sat on a database, so the actual front-facing Rails application sat on a different database and of course between the two they used Rails. That was actually just Rails using Rails but it made it very simple to connect them together, following that convention. This was a different use case, but we had a Rails application--we did a very big existing Java application on top of the complex database schema. they wanted to be able to have parts of the application actually be served out in Rails. And they wanted to visually merge them on the same page.
We actually chose something called pub-side Include which once you put XML tags in and have a server that basically pulls down the Java page that is rendered with JSPs and pull these XML tags which we then go fetch from the Rails application, HTML to fill in, and we cache it and do all that neat stuff. But it needed rails to work seamlessly with Java; now there you know Chad did some interesting work in actually integrating you know sessions in the database and things like that, so Java using JRuby by the way was writing the session data into the Rails session model and so that Rails could easily deal with that so that you had unified session management across Java and Ruby.
These were two different applications though; their whole goal was to break out pieces of the Java app-this constellation of Rails app and to eventually get away from Java. Visually it was fully integrated--very interesting you know kind of integration effort. And we've had other customers that wanted to just say okay, we want to expose this Rail--this REST API publicly. We want to design maybe a subset of our models, make them available to the public through a REST API and then help them in designing those things for that point of integration.
I've worked with a lot of XML interfaces to services that wing it. They say here is what you send, the HTTP requests, and here's the data you get back. The nice thing is Rails is so regular in what it sends back, they're easy to parse into whatever language you want to parse it in and it really, really helps people. I think that more and more folks are trying to focus on you know the piece of the ecosystem here and how can I make my piece talk to these other systems the easiest way possible and REST seems to be gaining a lot of momentum there in general which I am very happy with.
Chad Fowler: Probably a lot of it is driven by the push from Rails just you know being as visible as it was but you are seeing a lot more of that both on the open internet and now internally in organizations, so stuff like Fireeagle, interestingly does almost nothing. I don't mean that in a negative way, but it's just a tiny service and it's interesting that they've come out with this thing. Of course it harkens back to the way Unix systems have always been designed where you have little applications that do one thing well. We're seeing more of that on the internet.
The actual reason that these REST services were originally created by the Rails team was partially for providing internet access actually specifically with the CRM application that 37 Signals does, but a lot of it was David was looking at their own applications and particularly Basecamp and it was a lot like most big Rails applications at the time. It was just this nasty behemoth with huge controllers, with long actions stretched out across multiple pages and basically just bad code. A lot of that is there was no convention to force you to put stuff in the right place but I think a big part of it was we didn't really have an idea of not just where--when you put stuff into a new controller or new action, or what you call it, but when should you make a whole new application?
This whole SOA thing that's happened over the past several years and web service--since all this complexity came up and in order to help solve this problem that monoliths are not good and it's better to have small services that do the things they do well, and more and more people are using the REST stuff in Rails to intentionally--not from an integration perspective but to intentionally composite one application, one end-user experience from many small applications that do their job as well. That's something I've done myself, and also seen people talking about at conferences and people in training. It's obviously a trend in the Rails world to take advantage of this stuff to architect the systems well.
There's a trend I've seen in the web world and it's this dreaded word called scalability. The interesting question about scalability is shared nothing versus shared everything. When I look at pieces of a Rails application I see that a lot of the sharing problem goes back to a single monolithic database. The trend I've seen is to break that out whether at memcached or CouchDB or the Amazon services. I wonder if some of the criticisms of these so-called MBC frameworks where the model is just a thin veneer over tables is the problem. Is that going away some? Are we moving away from the ActiveRecord-type model toward I don't care where my data is as long as it can speak REST to get it and update it?
Rich Kilmer: I think that it depends on what systems you're building and for whom. You go inside of the corporation, we have a lot of them in the world, and their systems don't have to scale to millions of concurrent users. They really have the relational database thing going and they want to sit on top of you know relation databases as a storage technology. I think the Active Record model is going to be used for a long time to come. When it comes to other types of applications that do need large scale and large architectural scaling, I definitely think people should look beyond ActiveRecord or relational databases really and start thinking about other kinds of approaches towards storing data and/or performing computation in a distributed fashion, and dealing with things like concurrency which is way beyond threading, you know, massive concurrency. All of those things require different ways of thinking about your problem. There's an opportunity with things like Big Table and other types of table in the cloud type storage systems that we can get away from traditional relational databases and move to massively scalable distributed systems, but I think there are different classes of problems that need different kinds of storage.
That example of the app I was talking about, we had a front facing Rails
application using a backend Rails application; that backend one sat on the
database. The front one actually didn't. We moved information to the front
system through the file system. In that model this is kind of an interesting
architecture thing; they needed the Rails up on the front end that would render
a catalogue very quickly. They had so many items that the catalogue was only
updated about once every five minutes. You could say that we were caching, but
we were caching to the file system by generating source code, driving it into
the file system, rsyncing it out to a bunch of Rails apps that would read these
things in and it was ActiveRecord but it was in something called "Base without
Table" so it was not based on a table per se but they were model objects and
they were in memory. It would just pull these things in from the file systems
eval them up. They'd come into memory and refresh the
system and it was incredibly fast. It didn't touch the database at all to do
that. All these Rails instances could sit there and you could scale that
literally horizontally out.
Now where we did touch database we came back and that was a database backed system, but for a lot of the rendering stuff you don't need to touch it and you get things like caching. There're other approaches you can use, other kinds of data models--things like Maglev which is an up and coming Ruby implementation on top of this massively distributed object store. It's going to be a very different way of actually storing object graphs and getting objects because you're dealing with object graphs. You don't need to ORM them.
That was the impetus for my question. I was about to ask if ORM is dead or it should be.
Rich Kilmer: I don't think it's dead because there's a lot of relational databases out there and there's a lot of information in them and it will be in them, but different problems, different classes of problems require different kinds of technologies.
Chad Fowler: Yeah; it's kind of like you know I don't know if you've worked in big corporations where everyone uses a spreadsheet as a database and they just email it to each other.
I've used a spreadsheet as an application and they emailed it to each other.
Chad Fowler: Yeah; there you go so most of that when that happens you feel sick and you're like hey this is not what Excel is made for. Excel is a really good tool. Its warts of course, but when you're using it for what Excel is made for which is doing declarative computations across tables of data it's really cool. It's not a relational database though, right.
The problem I think is that everyone, just because of where we are in history right now, assumes that a relational database is the answer when really a relational database is a bunch of tables which is not relational by nature and it just so happens that we use it that way with relationships. When you have an application that actually has that kind of profile where it's a benefit to you to be able to relate data across multiple tables in that way and to do calculations inside the data source, relational databases are great and ORM is a wonderful thing to map the way we think in objects to something that doesn't naturally map there. The thing is a lot of the apps that we make, especially in the profile maps that you do in Rails that mapping layer, that necessity to go from thinking about data one way to the object way to the table way is a completely wasted step because you're really just dealing with object graphs.
I'm thrilled personally about the prospect of something like Maglev really working out--the Gemstone stuff because I don't want to think about SQL. It's not because I hate SQL; it's because I hate SQL for the sorts of problems that I tend to use it for. I think I'm agreeing with Rich there but I do think SQL and relational databases and therefore ORM are way over-used in the industry right now and it's really exciting to see not just Maglev but you know BigTable and Simple DB and all these things coming up and gaining some mindshare in making it at least reasonable to now talk about this as opposed to people looking at you like you're crazy if you suggest anything other than relational database.
That's what I found a little bit ironic about what Rich said. Maybe I have a misunderstanding here, but it almost sounded like Rich, you were saying these were these legacy projects where we need to hook Rails up to it and in that case using Active Record using ORM is the way to go, whereas the story I've tended to hear from Rails best practices--and I know you hate that term--is that Rails is great for new projects where you don't have these legacy concerns.
Rich Kilmer: No; you can actually do both with them. I mean it's very easy to map in even the worst schemas in the world to Rails. I mean it's not hard to do. It can be hard to do but it's not typically that terrible. Greenfield is great too with the relational database. What I'm saying is to me it's not as much a technology decision these days as it just a here's what we do. You go to a company they're going to say yeah; we store all their stuff in these big Oracle databases and you don't really have choice. That's what you do. They don't want to put things in an object database; they want them in a relational database. That's their policy; you aren't going to change that and you know and--but also say okay we'll store all this stuff in this big Oracle store that's fine or you know MySQL or PostgreSQL or whatever else. There are classes of applications where you're going to need to store things in relational databases out of policy--reasons; it's not technology.
Chad Fowler: Are you saying that policy is the only reason to use a relational database?
Rich Kilmer: No; I think that there are classes of applications where people in relational databases can be really good. I think there's some that aren't. If you want to make a technology decision you make the technology decision based on what you're trying to do I'm just saying in this corporation those are not really the reasons that drive the decisions people make; that's all.
Right; and I can understand that. Let's move onto the conference. I think we have a pretty good sense of how you both see the world of Rails right now. When you were putting together the Conference were there themes that you deliberately tried to bring out or were there themes that came up organically?
Chad Fowler: We tend to not really--actually I can't totally say that truthfully but you know we tend to not really try and push themes as much as talk about what they are. In the case of this conference it's no different. With Europe it is a bit different from the International Rails Conference that happens in the US in that the European community is pretty different from the one in the US, but there are actually two directions. The largest theme is really about the maturing Rails development process and best practices and that sort of thing. There's a lot of less of "here's how you do TDD" because it's kind of assumed that everyone does that now which is a nice place to be. Of course they call it BDD but whatever--and even REST, whenever you encounter some of these sorts of terms in the proposals that have come in, they're mostly about advanced usage of these technologies and special cases and things you might come across. We're finding a lot more of "here's how you integrate with a bunch of different technologies" or "best practices for using JRuby." JRuby is really big in Europe because Java is really big in Europe, and JRuby is the way to get that in or get Rails into the corporations in Europe. There's that kind of solidifying here's how to do it right--not just how to do it anymore.
Then the other thing is the track of what Rich was talking about with databases changing and distributed processing and all that sort of stuff. There's definitely a lot of exploration there taking place. One of the big trends over the past year in the Rails community, and I'm not sure if it's true in the rest of the web community in the same way, is distributed processing so. I know in Europe we'll have a talk on Starling which is the system that Twitter created--distributed job processing, but there are a number of projects that are active and seeing a lot of use now. I can't actually even name all of them off of the top of my head, there are so many for doing this kind of distributive processing work. We're seeing a lot of that. Justin Gehtland has a whole talk on how to compose applications out of small pieces, which is again part of this theme. Those are guess the two biggest trends that I see--compositing and distributed processing and data storage as sort of the leading edge. Most of it is just tightening up the way we're doing Rails apps.
Rich Kilmer: Matt Wood is talking about the human genome project and the work that they've been doing. He actually talked at Rails Conf Europe last year too.
Chad Fowler: Yeah; he gave a lightning talk.
Rich Kilmer: That's right. It was actually one of the most compelling things I've heard. His talk on genomes on Rails goes through the whole way in which they're using Rails and Ruby to streamline their pipeline of things that they need to do for genome sequencing and it's really neat to see it actually used in something like this big distributive system, which is going towards this really great purpose. It's not only a rapid prototyping thing; it's actually using that and it's using different languages. He's going to be talking about all of that stuff. That was an awesome little lightning talk that he did last year and now he's giving a full talk this year on it. I think that's going to be a real interesting thing. This is a person who is actually making real use of it doing something that is transformative to people.
Chad Fowler: I don't remember the numbers exactly, because they were so big I couldn't grasp them, but when he was talking about like how much data he's pumping through Rails at what rates, it was insane. He made a joke in his lightning talk saying if anyone ever tells you that Rails can't scale, they need to talk to me because it was just crazy how much data was pumping through this thing.
When you were describing the types of talks it sounded like they trended towards moderate to experienced Rails developers. Do you have a lot for beginners or is this for experienced programmers?
Chad Fowler: That has changed considerably every year of Rails Conf since we started in 2006, and so this is the third year. The first year it was a lot of "here's how to use Active Record". This year when developing, I guess I lied, this is one way that we did influence the program. We specifically asked for advanced content and we did it both on the International Rails Conference that we had in Portland in May or June I guess it was this year--the first couple of days in June, and again in Europe. We have maybe no beginner talks at all. I'm pretty sure that's the case and that was partially powered by and driven by feedback from previous years, and a lot of it is just the community is growing up and the people who are showing up there are so many resources available online that you can learn the basics of something you know on a weekend, using your web browser.
Also when you go to a conference or really go anywhere and you sit and listen to something I find that if I'm a little bit lost because it's going too fast I feel challenged and excited and I don't mind if it's going over my head, but if something is too slow then that's just boring. It's never okay for something to be too slow, so we're trying to in all of our Conference material blow you away, if anything, and you're going to be struggling to keep up because then you can go back and read up on the things that you didn't understand. The feedback from the International Rails Conf was overwhelmingly positive on that change which was completely intentional on our part.
I'm just giving Rich a chance here.
Rich Kilmer: No; I think Chad did a great job.
Chad Fowler: He agrees.
Let's talk about Ruby itself a little bit. I know the last couple of Rails related conferences that I've gotten to there's always that here's how you do meta programming in Ruby and you know as much as Rails can or cannot be a separate entity on its own there's still a lot of this is made possible by Ruby. What's the Ruby content look like here?
Chad Fowler: I have the worst memory in the world but I have the schedule open so I can look at it. Yeah; that's really where the tutorial like content does come in because a lot of people came into the community thinking they wanted to do Rails development and some of them didn't really know that wasn't a programming language. That's sort of a problem we have. A lot of people have said in the past that Rails is the gateway drug to Ruby which is definitely true so the materials that we have then is tutorial arranged and it is really Ruby kinds of stuff like Neil Ford is doing something on meta-programming which is always a hot topic and probably will be for a while just because the Rail style itself comes from that and we have other talks on like Tammo Freese doing one on extending Ruby and different ways that you can extend Ruby. He's a long-time Ruby(ist) and I don't even know if he does Rails development, actually. As people get really into Rails, they realize that this magic thing that wooed them from Java or whatever isn't Rails; it's Ruby as you said. It's the advanced Ruby topics that really get people energized when it comes to learning new stuff in the Rails space.
Rich Kilmer: I think for example, Jonathon Dahl is actually doing a talk on EC2 and Map Reduce distributed processing with Ruby. That kind of talk although a lot of times it will seem so back-ended by Rails, users of those kinds of services, those are all Ruby and I think that you know a lot of the folks are doing obviously massive amounts--I mean building a Rails application is building a Ruby application. It's just a certain structure of a Ruby application. Specifically in these areas of distributing processing, people are finding high interest in using and wrapping these services.
There have been a lot of interesting like regional conferences in the US and about Ruby. and we're going to have you know Ruby Conferences and things like that that focus a lot on that. Now those also have Rails content, but they kind of tilt towards a lot of Ruby-specific content maybe outside of the specifics of Rails. Ruby has a lot of interesting other domains that it can actually apply to and the means of complexity where you want to layer that complexity behind a really nice language as Rails does for you--we talked about the kind of database driven web world. It doesn't have to necessarily be database driven anymore but I'm saying that world with the web, there's a lot of other interesting domains like telephony, and things like Adhersion that map the telephony domain behind a really nice Ruby domain specific language. Ruby has some tremendous potentials of moving out beyond just Rails into other domains and there's a lot of interest in that from people that are using even Rails; how can we actually layer some nice rich Ruby API or Ruby language, if you will, a DSL, on top of our domain outside of Rails or anything else?
Chad Fowler: Yeah; one of the kind of hit talks from the last Rails Conf which was a surprise, Ezra Zygmuntowicz did a talk on--it was going to be on Scaling Rails but it ended up being about a project he's working on for Engine Yard which is driving their crowd computing platform and I'm sure Engine Yard will be talking about it at Rails Conf here as well. It's called Vertebra and it's actually a very Rails like and RESTy system for doing system to system communication in a P2P network. Actually they're using ejabberd to drive it, and then they're running Ruby DSLs on top of that. That's one of those things where no one expected to hear about that but that was one of the things that everyone kind of left RailsConf excited about and it had nothing to do with Rails but it was Railsy you know and that's sort of what Rich is saying without calling things Railsy; there's room for a whole lot more Rail(sy) stuff to happen in different domains and it will probably spring from the Rails community or the people who are refugees from the Rails community because they're too cool for it anymore or whatever.
We're seeing a lot more of that and that's really interesting. Adhersion is one of the coolest ones in my opinion. Another one that is going on--not at RailsConf but at RubyConf is RAD--actually I don't know that it's going to be at Rub Conf now; I mentioned about RAD. We have a couple of proposals about RAD, which is Ruby Arduino Development.
Oh wow; that's interesting.
Chad Fowler: Yeah; and again it's a very Railsy DSL and it looked like Active Record sort of that Greg Bornstein did which sits on top of the Arduino stuff and actually generates code I believe on the cover so that you can program the Arduino in pure Ruby. But it's totally informed by Rails and there's just more and more of this kind of stuff happening in our community.
One of the big announcements, a lot of the buzz I heard from the International RailsConf this spring was about Maglev. I heard pros and cons about it. I'm wondering if you're thinking something like that will come along for the upcoming Rails Conference or we'll hear more about Maglev or is that yet another Rails implementation on yet another Ruby implementation that may not pan out?
Chad Fowler: I'm sure we'll hear more about Maglev. I know some of the Gemstone people are going to be at Rails Conf throughout and I know they've been making solid progress. I happen to know the people who are working on it and so I have a lot of faith that it's going to be--it's going to get done and it's going to be impactful. You know we've heard pros and cons out of Rails Conf about Maglev but the pros and cons were really--I believe what they said or I don't believe what they said. [Laughs]
Right; I'll believe it when they show me.
Chad Fowler: Exactly. Rich and I have actually seen it so we can say it does exist and it works and it's what they say it is. We haven't built full applications on top of it, so that will be one of the tests that it has to pass--how well it's usable and you know especially its object store--that's a different thing for real applications that we're trying to build. I believe that it's going to be big and it's going take away some of the pain that we have for both scaling which is sort of the marketing thing--scaling and speed, but I don't want to worry about that dissonance between relational tables and objects. It will just have objects and that's what I need. I'm sure that we'll end up hearing more about that. I think maybe doing a birds of the feather session on Maglev there where they can release more information at Rails Conf, gear up and take questions and that sort of thing.
Rich Kilmer: Yeah; I also like--I mean kind of make a plug beyond just Maglev as implementation worthy and of course you know ultimately being able to run fine works like Rails on top of that implementation really but then there's also implementations like JRuby which is making good progress; there's Ruby 1.9 which is coming along. JRuby does expose massive numbers of Java frameworks to Ruby programs and so for those that are working within Java's environment this can be a very powerful way of building applications. There are still lots of people working in the Java environment out there.
Chad Fowler: Yes; there are.
Rich Kilmer: I'm really heartened by that. The IronRuby work that Microsoft is doing to bring a similar type of dynamic language to both the service infrastructure on .Net but also into the client, Silverlight, actually being able to deliver Ruby and being able to run Ruby inside the browser to be able to manipulate the DOM in Ruby and to be able to actually use the vector engine like Silverlight in a composite engine on the front-end in the browser. What's interesting about each one of these things is it's Ruby on a different runtime with different capabilities and they use different focus. All of those things create a lot of potential. Of course the work Apple is doing with Mac Ruby to seamlessly integrate Ruby with the Objective C runtimes, the Objective C runtime unifying garbage collection that is Ruby 1.9 now--garbage collection on the Objective C collector. Now you'll be able to build extremely performing full applications on Mac OS X in Ruby and it won't be something which is just bridged. It will be something that actually sits on the Objective C runtime, and fully exposes the Cocoa API that Apple has there, and Mac is becoming a bigger and bigger marketplace. Each one of these platforms brings some unique opportunities for Ruby, for frameworks that exist on top of it--I think for Rails but for other things as well. All of those, including Maglev, create a lot of good future potential.
Chad Fowler: And Rubinius which we left out which is another talk at Rails Conf Europe. I think the talk is called Rubinius 1.0; I don't know if that means it's going to be done. I think they're probably releasing it at Ruby Conf later on, but my nerd persona loves the fact that they're building this hacker-friendly Ruby implementation. I played with adding stuff and fixing stuff in it myself.
Rich Kilmer: The interesting thing about that is that because an implementation of Ruby is written substantially in Ruby, other runtimes that have built interpreters, for example JRuby, they're all sharing this specification system that Rubinius started and grew out this massive thing to say what is Ruby? Ruby is what these specs execute and say it is and so Rubinius is using those. There is the desirable Maglev group too--actually uses the same thing and JRuby is using that, of course Ruby 1.9, so Rubinius is actually going to yield a really interesting runtime and grow to be something which is really mature. It's also yielding a lot of code which can be reused to say we want to build this language in itself like the Smalltalk implementations were substantially but Ruby has not been because it was implemented in C.
Rich, what one or two things are you most looking forward to for this Conference?
Rich Kilmer: I am personally very focused--or very interested in the talk on the genome technology--what they're doing in the human genome project--and how they're using Ruby and Rails to simplify the work they're doing because I just think it's an awesome project.
Chad, how about you?
Chad Fowler: For me it's the one that I just mentioned which is the Rubinius 1.0 talk. Partially because I'm sort of involved in that project but even if I weren't I feel like--and I've said this before, that Rubinius may end up being the defacto standard Ruby implementation that people use, so 1.0 release from a team that has a good track record of only committing things that they believe in to be good--that's really the only purpose of Rubinius is to do it well. It's not an integration thing; so there isn't really a benefit to just making it work at some point as there would be if you were trying to build something to integrate with other technology. For them to actually call something 1.0 is really exciting and a precursor to larger adoption of this more hackable VM for Ruby and hopefully the beginning of the end of a kind of common complaint: Ruby, the language, is great and Ruby, the runtime, is not great. It would be great if the defacto implementation that runs [well] and something that we could all be proud of. I think Rubinius has a chance of being that.
Transcript provided by Shelley Chance t/a Pro.Docs