Ruby on Rails 2.0 has been released after many months in development. InfoQ had the opportunity to speak with David Heinemeier Hansson, the creator of Ruby on Rails and its biggest proponent.
David Heinemeier Hansson is widely known as the creator of the web-application framework Ruby on Rails, the infrastructure software that we use to build all our applications at 37signals. He was born in 1979 in Copenhagen, Denmark. After he graduated from Copenhagen Business School in 2005, he moved to Chicago, USA. He is a partner in 37signals, the company behind Basecamp, Highrise, Backpack, Writeboard, and Ta-da List. For his work on Rails, David won Best Hacker of the Year 2005 at OSCON from Google and O'Reilly. And in 2006, he accepted the Jolt award of product excellence for Rails 1.0.
Rob Bazinet (RB): Now that Rails 2.0.1 is out how do feel about what the team has accomplished?
David Heinemeier Hansson (DHH): I'm incredibly proud of everyone involved has been able to put together. It sounds crazy to think that hundreds of people from all over the world should be able to work together on releasing a framework used by thousands more. But it really works. Large-scale open source projects like Ruby on Rails highlights the best of remote collaboration and programmers working together across time, country, and language barriers.
The final product is very impressive. Rails 2.0 is polished in a way that's very hard to describe meaningfully in words (what does hundreds of tiny changes really mean?), but very apparent when you use it.
RB: If you sit back and look at what you and the Rails community has created since its inception, could you ever imagine it would have come this far? I mean, with all of the developers, products, training, books, conferences and other community support.
DHH: Not in a million years. I knew that if I liked working with Ruby on Rails, others would probably like it too. My programming taste and aesthetic is not a unique snowflake. Lots of other people are likely to appreciate the same things I do. But there's a huge leap from that and to the insane, mind-blowing uptake we've seen with Rails in such an incredibly short period of time.
Perhaps I was a bit cynical, but I would probably not have thought that an open source project run by people who don't consider it their day job would be able to make the waves it did. But I'm of course immensely pleased to see that it was possible.
RB: How do you see the world of Rails continuing to evolve over the next number of years? It's not fair to ask you to predict, I am wondering how you hope to see it evolve.
DHH: I hope that we continue to solve our own problems and share them with each other. That we don't give up on our vision and opinions in the vague hope of somehow attracting ever more people to Rails. Not everyone has to use Rails. As much as it is a technical framework, it's also about flavor and style. It would be very boring if everyone liked the same restaurants or everyone wore clothe from the same designer. We need choice and differences to keep it all interesting.
So if we can just keep the steam going on the train we have now, I'd be more than happy.
RB: The list of updates is pretty large, how easy do you think the adoption to Rails 2.0 will be considering the possible breaking changes in 2.0 from previous versions? Also taking into consideration how some of the conventions have changed including moving some functionality to gems instead of part of the framework.
DHH: We've spent a lot of time making sure that migrating from Rails 1.2.x to 2.0 wouldn't be too painful. Rails 1.2.6 is packed with deprecation warnings that allow people to get ready for 2.0 in a controlled way. Once your application runs beautifully there, it should be a short jump to 2.0. And anything that was pushed out to plugins is a single command away from being back in your application.
RB: What sort of changes to the Rails framework occurred in this release to go from a 1.2.6 version to 2.0? What are those changes that indicated to the Rails team it needed to make this leap?
DHH: Major versions usually indicate that backwards compatibility is no longer guaranteed. That's why we did it like this. We had a backlog of cruft that we wanted to clean up and going 2.0 was the way to do it.
RB: I have heard the Rails code base has grown to almost 94K lines of code from 54K or so in the last release. How do you feel about this? Is this a concern when trying to keep a framework simple? Maybe this is not a relevant question but I found the numbers interesting and wondered if they interested you.
DHH: I'd say that Rails in many ways have gotten simpler as the number of lines has gone up. More concerns have been abstracted to the point where you don't need to worry about them unless you're doing something unique. That's how it should be. Lines of code by itself doesn't really mean that much to me. What you're able to express in those lines mean a lot, though. So if you're able to write the same piece of functionality in 10 lines instead of 100 lines you've made huge strides in simplicity. That's part of the argument for why Ruby is a more pleasant language to work with than say Java or C#.
RB: Tell me what you feel as the most important features are to Rails 2.0 and what features developers should be most excited about?
DHH: I think our focus on RESTful application development is the biggest theme for Rails 2.0. It manifests itself in a bunch of features. From how you can map resources in routing.rb to our multiview support with respond_to to HTTP Basic authentication and more. The RESTful way of developing web applications really is a satisfying paradigm shift. It might take some time to understand and appreciate it, but once you do it really just clicks.
I know Rails is some shops with large numbers of users like Twitter, but.....
RB: Are any of the new features/updates meant with scalability for enterprise or larger application in mind?
DHH: Any feature we do that makes developing applications simpler is going to reap even bigger advances on larger applications. If you cut down the number of lines needed for an application by 20%, you're only saving 200 lines in a 1KLOC application, but 4,000 lines in a 20KLOC application.
As far as scalability goes, nothing has changed, because nothing needed to change. You've always been able to linearly add more hardware to make your application deal with more users (the definition of scalability). We've made some really nice improvements to the performance of Rails, though, so each individual server will be able to handle a bigger load (lots of caching optimizations in the code).
And we've improved our usage of HTTP so the perceived speed of a Rails application is greater too (asset caching being the biggest deal).
RB: How do you see Rails benefiting from such projects as Rubinius or even Ruby 1.9?
DHH: Everyone wants free speed. For me, it's in no way a requirement, but certainly a welcome gift.
RB: Microsoft has been making some strides with IronRuby and before too long we may see Rails on .NET. This is in line with JRuby and running Rails on the Java VM. To me this sounds like great ways to get Rails into enterprises that have standardized on .NET or Java. How do you see this as being a win for Ruby and Rails and what are your thoughts?
DHH: The more people get exposed to modern development frameworks like Rails, the less likely they are going to take crap from the mainstream environments. Hopefully that'll mean a rising of all boats. So Ruby on Rails running on existing enterprisey infrastructure is a good thing in my book.
RB: David, thank you for taking the time today to speak to me about the latest release of Ruby on Rails.