Ruby on Rails: First Impressions

In getting Potion Store integrated with my site, I had to learn Ruby on Rails. RoR has always been one of those things I’ve been curious about so I saw it as an opportunity to dive in. I present here a first impression. Note that these are impressions. They represent how I perceived things coming to it for the first time. While chances are that these perceptions are inaccurate, there’s something to be said for seeing how things appear to fresh eyes.

Ruby is an interesting language. It appears to be very flexible and dynamic, allowing you to do a bunch of really neat things that you can’t in most other languages. Note that these features aren’t really unique to Ruby. My sense is that Ruby is not a distinctive language in itself so much as a mostly good mix of other languages. I say “mostly” because I’m not sold on the syntax. It reminds me too much of Perl. It’s like they created a great new flavor of ice cream and then mixed in glass and razor blades.

My advice to those picking up Rails for the first time, get the Rails book and read the first few chapters before diving in. I found the online tutorials kinda annoying and not as good at explaining the structure and conventions that Rails relies on. Rails’ strongpoint is streamlining common tasks and functionality but to do so, it expects things to be laid out in a certain way. The other thing that takes time to figure out is the “magic” that Rails performs at certain points. One of the great things about Rails is how certain things are automatic. Very little glue needs to be coded and I feel that’s a wonderful thing. On the downside, sometimes this magic makes it hard to figure out what’s going on. For instance, some classes had naming patterns for their methods that you had to find out about in the documentation. I found the quality of the documentation to be a bit uneven which didn’t help in some cases.

I feel most of the problems with Rails are less about the design and more about the implementation. For instance, Rails is a memory hog. And because Rails is single-threaded, you need to have at least two of these things sitting there to get any sort of concurrency. When I deployed my store, I had to upgrade my SliceHost slice as the 256M slice wasn’t cutting it (remember I’m also running mysql and PHP stuff). Also, I felt deployment was a bit clumsy, as I had to set up a cluster of mongrel instances to run my app with apache acting as a proxy. While I see that there is a mod_ruby for apache out there, no one I know recommended it. Nonetheless, I felt like I had to deal with more moving parts than was necessary.

In a nutshell, Rails: great, Ruby: enh. If you are going to buy a book on it, get the Rails book first. It has an appendix on Ruby that should be sufficient for most things. If you want to go deeper with the Ruby side of things, you can get the Ruby book as well but personally, I could have done without it.

Overall, I like the platform but at the same time, I can see that it’s relatively immature and has some ways to go. I’m pretty much tied to RoR for now since it’s what the store is written in but that’s not a bad thing. That said, I also am not so amazed that I am going to join the Ruby cult.

Nonetheless, RoR feels like how a web framework should and less like a bloated platform where you end up installing a hundred frameworks requiring just as many config files to be edited to solve non-existent problems that are justified because someone gave it a fancy technical name along with a contrived design pattern to fix it (if you need a hint as to what I’m referring to: “starts with a J”). RoR seems to be able to identify and address the actual problems people run into when creating web applications, all the while keeping it relatively simple, and that is refreshing to see.