Today is Saint John's day here in Porto, where Hive Solutions is headquartered.

Which means that tonight, thousands of people will hit the streets, in what is probably Europe's liveliest street festival, to bang each other's heads with plastic hammers, eat sardines, and watch fireworks. And I will too, just after I finish this post :). So, on a completely unrelated note, I am going to quickly rant on Ruby on Rails.

To Rail or not to Rail

Rails rocks, or so they say. Until now, I knew very little about Ruby on Rails. I knew what it was capable of, what the framework was meant for, who designed it, its as well as their history, their success, and all the associated hype that roams the web (and also knew a little bit of Ruby). Basically, my paradigm was: "For the scenarios it was built for, Rails rocks.".

But now that I have actually implemented some new features for another company's product, which was built on Rails, and had to learn it for real, some of the hype has dissipated, and I was left with reality.

1 - Ruby is just too awesome

Ruby is a very liberal language, in the sense that it has some nice features, like everything being an object, which allow people to create delicious syntax sugar at first glance, and cryptic mumbo-jumbo for whoever has to understand the code afterwards. For example, here's a creative way of creating a loop in Ruby:

5.times { print "This is one of the many ways you can loop five times." }

Cool as it may seem (and it is), if possible, I personally don't like having more than one way to do a thing, since I feel that it makes it just too easy for a team to create a messy codebase, in case they haven't agreed on strict code standards beforehand.

2 - Rails is just too damn helpful

Rails shortcuts a lot. In its quest for DRYness (Don't Repeat Yourself 'ness), it provides a lot of default behaviour (example: default template routing) which in the beginning provides a developer like myself with a pleasantly paranoid frustration of having things work, but not understanding why, which may be interesting when starting from scratch, but completely sucks when you're building stuff on top of a codebase that isn't yours and you're still not done grasping it completely, as you have Rails' smoke and mirrors making that job harder (this is obviously a very personal rant :P).

3 - Rails is stateless

This is one of the reasons I wouldn't trust Rails if I was going to build something big. The need for state, would pop in at one time or another. Just on the top of my head, if I wanted to have a scheduling task, I am not seeing my way out of having to run a cronjob, and getting out of the development stack truly sucks for many reasons, one of them having to do with portability.

4 - Rails is not modular

This is the ultimate reason why I won't do anything big in Rails, I am addicted to modularity, so I would use Colony instead. Taking all the advantages that runtime modularity brings out of the equation, just the paradigm that Colony would impose on my development, by forcing me to separate my application's concerns gracefully, would pay off so damn much in the long run, that I wouldn't consider any other option.

So what?

My opinion may change, but currently, if I was going to build a small project with very specific requirements, very fast, I would probably use Rails, and if I was doing something big, I would use Colony. Anyway, I don't see a reason why Colony won't be able to beat Rails in this regard as well in the nearby future :).