When Rails first started gaining some momentum, I took a look at it. I heard some good things about Ruby as a language, and it looked like an interesting system; unfortunately, what I saw and read about it bothered me. The Rails platform seemed to handle a little too much, and my trust in brand new code generation systems is usually pretty low. I also did not like how things like the file structure were locked in and yet influenced the application operation. And, there were some things about the Ruby and Rails communities that rubbed me the wrong way. I know that's not a rational reason to make a tech decision, but when you are looking at a fairly new, immature, open source technology (which Rails was at the time), if the community does not feel comfortable to you, things are going to be rough.
A lot has changed in the past several years. From my perspective as an outsider, the biggest, most important change has been Engine Yard's involvement in the Ruby and Rails communities. The company has brought a level of support and structure to the ecosystem that enterprises require in order to place a bet on a technology. Engine Yard also put a lot of money into getting things done, and the company seems to be assuming a leadership position and giving the development efforts a place to live and some direction. These are all great things, and now that Rails 3.0 has been released, I'm taking another look at it.
What's different about Rails 3.0?
I spoke with Dr. Nic Williams, one of the top Rails developers and the VP of technology at Engine Yard, to find out what was different about Rails 3.0, and why developers should check it out.
The big news in Rails 3.0 is that it is a significant rewrite of Rails. The major goal for the rewrite was to make it possible for Rails to be much more extensible without requiring that plugins be rewritten when Rails gets updated. A while back, Rails merged with the Merb project, and this was part of that merger. Rails had a particular way of doing things, and it was not so friendly if you wanted to do things differently. Merb was quite the opposite, so the new framework allows authors to drop in code to replace existing functionality very easily. Unfortunately, that broke some existing plugins and code along the way, but with a six month beta period, there has been plenty of time for developers to get ready.
Existing Rails developers will notice that there are a number of new APIs, and some of the existing APIs have changed. It is likely that existing apps will require some changes. The routing syntax is an example of a change. But there is a better dependency maintenance system, which will reduce pain in the long term.
One of the standout concerns of many developers (including myself) who looked at Rails in the past was the lack of control over Rails' functionality. With the rewritten internals and the collaboration with Merb, this is significantly improved and warrants a second look at Rails. Dr. Williams explained that Rails 3.0 offers extremely rapid development. A large part of that is the Arel system for working with databases. It is very similar to LINQ to SQL in that it is a SQL-like syntax for making queries that abstract the database away. Also like LINQ, Arel is going to be extended in the future to work with non-SQL data sources, such as XML and YAML.
Developers' feedback about Ruby and Rails
I have not worked directly with Rails, so I got in touch with three developers I know who have used Ruby and Rails to get their unfiltered feedback. Here's what the developers, all of whom I respect greatly, had to say.Sterling Camden
I program in Ruby almost every day. It's my language of choice for heavy-duty scripting (basically, anything that sh can't do easily) and has pretty much replaced Perl in my arsenal of tools. I love Ruby as a language, because it's object-oriented when I need it to be, and not when I don't. I can be as FP as I wanna' be, too — or I can cheat and be imperative if that's what seems to fit the problem domain. The POLS means that Ruby is essentially a human language — sometimes the exact rules are difficult to remember or spell out, but they're usually what you'd naturally expect in any given situation.
I've worked with Rails some, but not nearly as much as I've worked with Ruby sans Rails (off the Rails?). I found Rails very easy to get started with, but more difficult to learn thoroughly. A lot of Rails behavior seems to occur behind the curtain. Contrast my experience with Django, which seems to me to be implemented extremely transparently. My analysis is highly unscientific, though, and may be colored by the point in my learning at which I encountered each of these frameworks. I need to revisit Rails to update my knowledge to version 3 (just ported to FreeBSD, I see!) — I hear things are implemented a lot more sanely in that version.Chad Perrin
While it was Rails that first drew my interest to Ruby, I stayed with the language. In fact, it was not long before I abandoned Rails entirely, because for the majority of my work — even for Web development — Rails is the wrong tool. Your mileage may vary.
Ruby is an extremely flexible language with a very natural-feeling object model that is always at my fingertips, decent support for both metaprogramming and functional programming, and an excellent community of knowledgeable developers behind it. Among the many reasons I use it are the way it encourages elegant simplicity and clarity of code, and the fact that programming in Ruby really is something of a joyful experience.
Frankly, I'm a happy programmer because of it. Ruby lets me write really elegant-looking code that reads like English poetry and encourages me to write elegant solutions that feel magical without losing the maintainability of well-written code being easy to understand and reason through.
It isn't the perfect language, of course. Its biggest "wart" is probably its speed, which is far from spectacular. Most of the time when speed is a problem, I find that the algorithm I've chosen is a much bigger problem than the language, but when I simply need something faster I don't resist the need to choose another language. Of course, newer versions of Ruby are supposed to speed up execution significantly, likely putting Ruby at least on par with Python, but I have not really played with v1.9 yet.
Unlike Sterling's case, it has not replaced Perl for me. I have use for both, and my regard for the utility of Perl has not been diminished by my use of Ruby. Each gives me things the other does not, and I keep both of them in my "toolbox" for when the occasion is right.Mathew O'Hare
The Rails framework is a great help to web development. I come from an application development background, so I come to a new site as an application to develop. ActionPack (the View and Controller components of Model View Controller) provides a screen-oriented development platform. I organize my screens around the various items of business data. ActionPack naturally supports all the basic actions on data. That makes it a breeze.
Let me give you an example for a book inventory application. We make controller class for books. In the class, we make public methods for viewing, deleting, editing, and adding books. This will be in a native Ruby script. Then we make a view for each of the methods (using embedded Ruby in much the same way one would do embedded PHP). Rails handles all the URLs, database updates, and many of the security concerns.
The only drawback I have with Rails is the ActiveRecord class. The Rails paradigm is to handle most of the database actions in code. I'm a database purist, so I'd rather let the database engine do more of the work for the safety of the data. Still, it's a small price to pay for all of the advantages in the ActionPack part of the Rails framework.
Reading the feedback from these developers, my impression is that the Ruby language itself is a winner (which has been my impression of it as well), while Rails will not be everyone's cup of tea. I find it interesting that the general objections that Sterling and Mathew both have is where Rails takes control away from them. I'm curious to see how Rails 3.0, with its emphasis on extensibility, modularity, and giving more control to developers, will change developers' opinions about Rails.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
Justin James is the Lead Architect for Conigent.