Few can have missed the rise of the programming world's latest star platform—Ruby on Rails. Rails' creator, David Heinemeier Hansson, already wowed the crowds at this year's OSCON and is set to keynote the European O'Reilly Open Source Convention in Amsterdam this October.
Heinemeier Hansson lives in Copenhagen, Denmark, and is a partner at the innovative 37signals, creators of the Basecamp project management web application. O'Reilly Network talked with him about Rails' success and future.
Edd Dumbill: Rails is now getting wildly popular. Did you have any idea it would take off as well as it has, back in 2004?
David Heinemeier Hansson: Yes and no. I don't think you can predict, much less plan, the kind of success that Rails is currently enjoying. But I did have a good feeling about the possibility of it taking off, mostly because I felt so good about working in Rails myself. And I thought, if this stuff can improve my enjoyment and productivity so much over the conventional approaches I had used in the past, why shouldn't it be able to do so for others?
I think I represented two backgrounds that are both fairly common in programming. I had been working with PHP for a long time, so I had that exposure to getting things done quickly, caring about seeing results before all else. And at the same time, I had been educated at the university and worked with Java in a J2EE shop for some time. That gave me the exposure to really care about the purity and maintainability that good patterns and practices can give you.
So I was situated at the intersection between two widely popular approaches to software development. The one represented by PHP was quick-n-dirty and the one represented by Java was slow-n-clean. So combining those influences into the ultimate goal of quick-n-clean did give me some confidence that I at least had a shot at appealing to both camps.
ED: What do you think is the key to Rails' popularity?
DHH: There's no one key. That is, there's no single, big innovation in Rails to point at and say "that's why." In some ways, that makes Rails harder to explain because the hook can't be both concrete and a one-liner at the same time.
David Heinemeier Hansson
O'Reilly European Open Source Convention
But let's focus on just one of the keys: Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works.
With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.
That's not necessarily an easy sell, though. Just see all the wars through the times over coding standards. If people could just agree on one way of placing their brackets, they could presumably reap more readable and uniform code. But for a lot of people, that didn't work because the trade wasn't appealing enough. Getting a more uniform code base is frequently not treated as importantly as individual "freedom" by a lot of programmers.
Rails essentially tries to do the same as the coding standards did, but the reason it's working better is that the deal is much sweeter. Getting a uniform code base is an abstract, group-centered goal. Seeing your application work in a fraction of the time it took you before is a very concrete, individually rewarding goal.
One characteristic of opinionated software is the notion of "conventions over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.
ED: What has been the most surprising or gratifying use of Rails you've seen so far, outside of 37signals?
DHH: I've been very gratified by seeing the success of 43things.com. The Robot Co-op was perhaps the first "major" company that picked up Rails shortly after its release. They had a very inspiring motivation for their work: to help people reach their goals in life. How can you not just love that?
And it works! I landed my keynote speaking engagement at OSCON in part because Nat Torkington saw my list of goals and noted that I had "deliver a keynote on Rails to 500+ people" on there. He got in touch, and this August, I gave a keynote in front of the 2000 people at OSCON.
But in general, I've been extremely pleased to see the broad uptake of Rails happen so rapidly and that we know we have a real economic ecosystem revolving around the framework. On our list of people working professionally with Rails, we count more than 3000 people from over 40 different countries. I'm continuously floored by that.
ED: What's your favourite Rails feature?
DHH: In general, all the things it doesn't do. All the features we said no to. All the ornaments we turned down. All the 20% solutions that solve 80% of the problem.
More specifically, I really like our domain-specific languages. The beauty of specifying relationships with
belongs_to, has_one, has_many and
has_and_belongs_to_many. The ease of using validations like
ED: When I first saw Rails, I must admit that it being Ruby made me think twice. It's an unusual language. How did you first get into Ruby?
DHH: I got into Rails in the summer of 2003. 37signals was about to embark on the development of Basecamp—which would ultimately turn the company from a consulting firm to product development. We had been using PHP for years, and I had tried as hard as I could to arrive at a reusable framework that would make my life easier. And I actually had a very early and at least somewhat decent reminiscence of Rails running in PHP at the time, but I wasn't happy.
And it was one of those "love it or leave it" moments. I realize that if this was going to be my working life, developing web applications, I had to be using tools that I loved, not tools that I merely tolerated. So I was open for alternatives.
Then my influences conspired. I am a big fan of both the Pragmatic Programmers and Martin Fowler, and I was seeing Ruby popping up time and time again from both of these sides. And a friend of mine had given it a cursory overview and challenged my reasons for staying with PHP.
So for a short while, I went into apologetic mode and built up all the stable arguments for why to reject change. We wouldn't be able to find programmers knowing Ruby for 37signals, PHP probably had more and better libraries, and on it went. But that thankfully didn't last too long because I decided to actually give Ruby a try.
It took one day to say, "I really like this." It took one week to say, "I'm never going back to PHP again." And it took one month before my proficiency with Ruby made me run circles around my former programming capabilities in PHP. It was just such an incredibly powerful fit. Ruby fit my brain perfectly. I was having so much more fun and getting so much more done.
I realize that this makes PHP sound bad, but it's really not about that. I'm grateful for PHP. It got me started with programming because of its incredible immediacy. It served me very well for a long time. I just arrived at a place that was outside what I would consider the sweet spot for that language. And Ruby proved to be exactly what I needed to get into the sweet spot again.
ED: Did you ever think at any point that Rails would have been better if written in Java or Python?
DHH: Better is such an inadequate and ambiguous term to apply to a comparison like that. If we suspend our disbelief for a second, I could imagine that Rails in Java would have an easier time gaining corporate traction. But that's just not an all-important criteria of success for me. I created Rails to help me do my work better and faster, not to drum up an attempt to move into that space. That it's happening anyway is great, but it probably wouldn't have if I had tried to consciously engineer it that way.
As for Python, I don't know. From the outside, the languages look incredibly similar. But from the inside, it's the small differences that make it feel like very separate worlds still. Python surely has a lot of cool stuff going for it. And if it wasn't for Ruby, I could certainly see myself in that camp.
I think Rails feels, smells, and tastes like it does exactly because its very Ruby-like. It plays heavily on the best in Ruby. The blocks, the ease of creating domain-specific languages, and so on.
ED: Would you ever consider recommending PHP or Perl to write a web app now?
DHH: Sure! Rails is not everything for everyone at any time. I use PHP myself fairly frequently when I just need a dash of dynamic content on pages. We use it for all the marketing pages at 37signals that just need a few includes and such.
Rails does, however, command a very large portion of web applications as its sweet spot. So if you're asking me whether I would recommend PHP or Perl or whatever to do applications like Basecamp, 43things.com, ODEO, Strongspace, and so on, the answer is surely no.
Your circumstances may well dictate that you do anyway, though. I think, however, those circumstances are often grossly overrated. For example, that just because you don't have any Ruby programmers on staff, you can't use Rails. Or because you've used another environment in the past, you can't switch. Hogwash. Good programmers are good programmers. And Rails is likely a lot closer to what you've been doing before than you think—minus a lot of the pain, naturally.
ED: One of the things I like about Rails is the differentiation between production and development environments. Those kind of features don't normally come built in with scripting language web tools. Did you consciously set out to provide some "enterprise" features in Rails?
DHH: I set out to serve me. Rails is a very selfish project in that respect. It gained a lot of its focus and appeal because I didn't try to please people who didn't share my problems. Differentiating between production and development was a very real problem for me, so I solved it the best way I knew how.
It's hard enough to solve your own problems with eloquence. Trying to solve other people's problems is damn near impossible—at least to do so to the level of satisfaction that would make me interested in the solution.
That's why we hold the notion that "frameworks are extractions" so very dear in the Rails community. Frameworks are not designed before the fact. They're extracted when you've proved to yourself that an approach works. Whenever we get ahead of ourselves and try to leap over the extraction process, we come back sorely disappointed.
I believe that's why Rails just feels right for so many people—because it's been used by real people for real work before we dished it out for others to reuse.
ED: Although relational databases cover 90% of use cases, there are times when different backing stores are handy. What do you think of adding alternative stores, such as an object database or RDF datastore?
DHH: Rails will happily serve up any model that you can imagine. Instiki, the wiki I created, has recently been ported over to Rails but still uses Madeleine (a Prevayler implementation in Ruby that works kinda like an object db) as a backend.
So it's quite easy to forgo Active Record and use something else as a backend. I've recently seen people use SOAP, SAP, LDAP, and a bunch of other backends. Or even just plain text files. It's all possible.
What has happened, though, is that Active Record has reduced the pain of dealing with the object-relational mismatch to a point where its a lot less appealing to seek alternatives—especially with databases like SQLite that give you the feel of flat text files, but within the context of SQL.
My personal enthusiasm for projects like Madeleine has thus dampened quite a bit as Active Record got better and better. It's not that other approaches are not cool, just that I don't feel the pain necessarily to ignite my interest all that often.
ED: Quite a few handy web frameworks have suffered from getting big and potentially unmanageable—Zope, for instance. What's your strategy to avoid this?
DHH: Stay below the infrastructure surface. Don't let business logic creep in the back door. It's not the responsibility of Rails to deal with content management, access control lists, forums, chats, or what have you. We're about the general structures that make sense of any kind of application.
So we won't ever become Zope. Or OpenACS. Or any of the other frameworks that have dipped into business logic waters and been consumed by it.
We're all about making it easier and easier to do what most people do most of the time in any type of application. For example, we're working on preparing a new sub-project called SwitchTower for the next version of Rails. It solves the problem of deploying applications to production servers. That's a problem that most every application needs to deal with, but it doesn't complicate the development process by making the default stuff any harder. It's just there, patiently waiting until that's your problem.
ED: What's coming next for Rails?
DHH: I've already hinted at SwitchTower as one of the major new elements, but otherwise, we're mostly about 1.0 right now. The final spit and polish.
After that, we do have a ton of plans, though. I'm especially excited about The Conductor. But I'll keep that guy under wraps for a little while longer.
Editor's note: You can also check out a Korean translation and a Japanese translation of this interview.
Edd Dumbill is co-chair of the O'Reilly Open Source Convention. He is also chair of the XTech web technology conference. Edd conceived and developed Expectnation, a hosted service for organizing and producing conferences. Edd has also been Managing Editor for XML.com, a Debian developer, and GNOME contributor. He writes a blog called Behind the Times.
Return to the O'Reilly Network
Copyright © 2009 O'Reilly Media, Inc.