Web Development

A fresh look at Rails and Ruby

Rails 3.0 emphasizes extensibility and modularity, and it gives developers more control. Hear what several developers have to say about Ruby and Rails.

 

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.

My take

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.Ja

Disclosure 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.

About

Justin James is the Lead Architect for Conigent.

23 comments
nwallette
nwallette

Calling in varied opinions was a nice touch. Makes for a well-rounded review.

apotheon
apotheon

Actually, that's much of the reason I stopped using Rails for my Web development in Ruby: because it takes so much control away from the developer. The Rails framework is great when your needs fit neatly within its very clearly defined design philosophy, but not when they don't. My needs, in just about every case, have not fit within that design philosophy. I know of others who have not had that problem, and happily, regularly develop Web applications in Rails.

Ubuntu Warrior
Ubuntu Warrior

How does Ruby on Rails compare with enterprise options like Java Spring?

Jaqui
Jaqui

almost as bad as python's twisted framework. don't need no steenkin framework to bloat up the code. :D the rally cry for developers needs to be Hardware Is Expensive, not the one being used of Hardware Is Cheap. code written to H.I.E. will be much easier to maintain, and will be far more likely to not be as bug ridden as the H.I.C. code is.

mattohare
mattohare

The ironic thing I found in the three quotes is that I'm definitely not the biggest Ruby fan of the lot. I'm still learning it, in fact. I most also say, that one thing I do like with Rails with ActionPack is it seems to give me more control.

Justin James
Justin James

I've never taken a close look at Spring. J.Ja

apotheon
apotheon

The moment you start calling your development framework "enterprise", I know that the buzzwordiness of the "solution" has gotten to be greater than its effectiveness and usability. There are very few cases, at least prior to Rails 3.0, where Rails is not better for the developers than Spring + J2EE. Unfortunately, its intended purpose is to make J2EE usable for Web development, and that's a bit like trying to push a six ton boulder uphill with your hands tied behind your back. Spring itself, minus J2EE, is nice enough. Its convention-over-configuration approach is a great way to design a Web development framework. It still requires development in Java, though, which means that there are limits on how painless it can make the development process. Java is just not a language that facilitates elegant Web application development very well. While I have little use for the narrow problem domain that pre-3.0 Rails and Java Spring serve, if I had a need for a framework in that space and had to choose between those two, I'd go with Rails any day of the week -- all else being equal.

Jaqui
Jaqui

you mean bloatware framework on top of bloatware language is usable? not by any sane person it isn't.

apotheon
apotheon

code written to H.I.E. will be much easier to maintain, and will be far more likely to not be as bug ridden as the H.I.C. code is. The "hardware is expensive" approach pressures the developer to use ugly performance hacks, and to start trying to shift bits with tweezers. The end result is that you have to write a lot more code than if you take the view that "hardware is cheap" and focus on writing clean, maintainable code instead. When writing that clean, maintainable code, you end up with a smaller codebase, a more elegant design expression in source code, and fewer implementation complexities that might otherwise produce -- and hide -- more bugs. I'd love to hear your explanation for why taking the "hardware is expensive" approach makes for more maintainable, less bug-ridden code. Maybe you mean something different by "hardware is cheap/expensive" than the way I understand the terms.

mattohare
mattohare

You have many sites going now? In honesty, I'm still on my first site.

Justin James
Justin James

I used to think that all of these frameworks were horribly "expensive" and such. Then I learned and realized a few things: * The framework authors are almost always much smarter and much better than the typical coder, and their code will almost always be less buggy and perform better than something written per-application. * When a bug/performance fix gets made, it's nicer to have to apply it once at the framework level than on a per-app level. * Managed code environments are nothing more than very large interpreters, working with compiled bytecode instead of textual source code. If you don't object to an interpreted language, a MC system shouldn't bother you either. * J2EE and .NET do *not* load "the entire framework". Just like any other system, they only load the libraries referenced by the developer. The *real* problem is that IDEs tend to include a few too many libraries by default to make life easier for the developer. Visual Studio, for example, includes at least 3 libraries which are not mandatory, baseline libraries to be running. * Unless you are the kind of person who thinks the government should pave perfectly fine roads as a form of "economic stimulus", it makes little sense for thousands of developers world wide to write and rewrite (and test/debug/maintain/etc.) the exact same functionality to identical specs when a small team of developers can do it in a framework. "Standing on the shoulders of giants" and all of that. * Homebrewed systems almost never add value that a framework doesn't. * How many developers (as a percentage) work on systems so large that scaling issues truly matter? Where 10 MB of framework code is going to be a noticeable difference? What, are you writing server apps that run on 386's or something? The .NET and J2EE systems have not grown nearly at the same rate as hardware. Take the .NET 1.0 or 1.1 systems which were knocked as "slow" when they came out 8+ years ago, those apps run dandy now. On top of that, the runtimes have gotten much improved as well. C# code, for example, is about 10% - 5% slower than equivalent C++ code. I would expect that slowness in systems like Django and Rails come more from the interpreter than the framework... it's not like the code goes all over the possible code paths just for fun. In other words, yes, the framework adds some overhead, but I highly doubt that it adds so much overhead that the average developer would replicate the needed functionality AND have better performance characteristics, and at the same time, the improvements in the development process more than pay for any hardware costs (which there should not be) for anything smaller than a giant server app. The only time handrolling still makes sense if your company is so massive that dev time is hugely cheaper than hardware... I'm looking at Google, Amazon, Microsoft, and a few others. A few thousand companies at most. J.Ja

Jaqui
Jaqui

the father of "hardware is cheap" development, Java, and tell me that it's less code. since you have to INCLUDE every line of the jre/jvm/j2ee as a part of the app, if counting lines accurately. same goes for .NET, and all the other application frameworks. the entirey of the framework is part of the app. then look at the 2.5 GB Eclipse IDE, that becomes a part of any app written in it. [ if it's the Java language ] hardware is cheap does not produce less code, or cleaner code, it means throw hardware at the problem to make it go away.

apotheon
apotheon

I've built three complete Web applications in Rails, two of which made it to live status on the Internet, one of which stayed for long. None of them were very big or fancy. I've also started building two others, then threw away the design and started over using Ruby but not Rails. Truth be told, none of them really needed to be done in Rails; in my experience, eruby suffices perfectly well for the majority of cases where Rails is the first choice, and provides more flexibility in some ways. I'm sure the experience of others varies greatly. . . . and, frankly, while I have some specific memories of the pain points and advantages to Rails, I don't have specific memories of the technical aspects needed to get it done. I'd have to mostly learn from scratch again to get back to Rails development. As I mentioned where quoted in the article, Rails was my introduction to Ruby -- but I didn't stick with Rails for long. Ruby, on the other hand, easily had enough going for it to keep me around.

apotheon
apotheon

Your comment was posted as a reply to me, but I don't think it's me with whom you disagree.

nwallette
nwallette

From more of an admin (vs. developer) perspective, I have different expectations of applications written for clients and servers. I can't wait for Java to die on the client side. The whole appeal for Java was to be universal -- write once run anywhere. Instead, every update installs side-by-side, taking up GBs of space and causing all kinds of versioning issues. I can't count how many times I've had to yank and reinstall J2RE because yet another update came out and now App X won't run anymore. Inexcusable. If you only run one application on your PC, and have tons of excess CPU and memory, .NET isn't bad. But it seems like every .NET application just feels a little heavier than an equivalent written in native code. And when I have 20 windows open, the disk just starts grinding every time I use an "interpreted" app that has been running minimized for a while, even when something like Chrome still feels pretty snappy. On a server, I expect to have to cater to the application a bit. But I also don't want to see some framework/environment eating more memory and CPU time than the production applications. Again, Java leaves a bad taste in my mouth. I also hate having to tune application VMs to make sure some process doesn't run out of allocated memory. Don't modern OSes do an OK job of memory management already? Finally, having administered a development environment with developers using Oracle, NetBeans, Eclipse, WebFocus, MetaMatrix, etc. etc., I can definitely see the difference between code written by developers that like to be pampered by IDEs and environments that do everything under the sun, and those that have a bit more finesse. It just seems like all the abstraction allows for lazy developers and sloppy code. There's a huge difference between benefiting from well-written reusable code, and languages with excess baggage.

Sterling chip Camden
Sterling chip Camden

I was pretty excited about Java at first, and I predicted that it would draw a huge market. But I was also disappointed early on about some of the design decisions that limited the language to the point where it was fated to die by spaghetti suffocation. Whenever a language provider refuses to provide the tools that people want, they always invent them rather than settling for your way of doing things. Unless the base system is naturally extensible (which was one of the things they left out), those add-ons tend to be unnaturally complex. Result: cruft^nusers

apotheon
apotheon

Look at what Java addressed: the problems of C++. Yes, it required less code than its "hardware is (more) expensive" predecessor. It is years of building cruft -- not the original "hardware is cheap" design -- that led to the current state of Java, where it's debatable whether it saves any code weight over C++ (and a case could be made that it's worse than C++ for scaffolding code these days). That's not to say that I like Java. It sucks, really. Its early days were successful in the effort to make an improvement over C++, though. hardware is cheap does not produce less code, or cleaner code, it means throw hardware at the problem to make it go away. That's not a development decision. I thought we were talking about software development -- not IT resource management.

apotheon
apotheon

I take the rule of thumb that hardware is cheap as a working assumption. If I start running into actual performance problems, then I start looking at where the bottlenecks occur. There are, of course, certain cases where I know in advance that performance will suffer greatly if I do not account for it in development, and in those cases I will take care with my algorithm for performance purposes up front (a simple example in Ruby is using

mattohare
mattohare

Irresponsible Expensive Hardware focus leads to bit-shifting hacks. Irresponsible Inexpensive Hardware focus leads to a framework that is repetitive and bloated. And, it still seems to want a lot of scaffolding code. I wish we could get Rick Mercer to do something on this. The moderate approach is what we need here. Hardware is not so expensive to require bit shifting hacks. But it's not so cheep to allow php-style bloat hacking either. That's why I like Rails. It could be more lean, but at least it's not ASP. It doesn't take loads of scaffolding. In trade for what it has in the framework, it does take out most of the code that used to put bugs into my aps.

Editor's Picks