The behind the scene code generation (aka: magic), the lack of a decent IDE, and worse, of a good debugger made my transition to Ruby somewhat difficult and sometimes confusing frustrating. I used to live in Visual Studio .NET and breath Intellisense. In fact, I still miss that to this day.

Any newcomer to Rails will quickly discover why it is so talked about. First of all, even though I don’t consider myself anywhere near a decent Rails programmer, I am now at least twice as productive with Ruby on Rails than with ASP.NET and C#. Thanks to the MVC (Model, View, Controller), DRY (Don’t Repeat Yourself) and Convention Over Configuration mindset of Rails. All the data access code is automagically generated for you (without running a code generator), templating is built in and creating AJAX’ed applications is a snap.

Life was good with Rails and the more I used it, the more I liked it. That was until early August of 2006. I was ready to launch version 2.0 of Ajaxwhois. Knowing so many professional Rails hackers, I thought deploying my application to my production server was going to be a breeze. I was wrong. Even though the installation of Linux (Ubuntu Dapper Drake 64 bit), Lighttpd, MySql and Mongrel went well, I experienced weird problems, mainly related to Mongrel. Sometimes, my Mongrel instances would simply die and disappear from the process list for no apparent reason. I didn’t have ANY traffic at this point because I hadn’t done DNS transfers yet. On other occasions, Mongrel went crazy and started peaking the CPU at 99%. I had to manually kill and restart it.

After extensive research and countless “from scratch” reinstalls, I found out that Mongrel was known to not play well with 64 bit Ubuntu (I lost the links to this evidence, unfortunately). Mongrel was patched accordingly, but it didn’t solve my problem. It still crashed many times a day and I just couldn’t figure out what was wrong. I asked my good friends Rich Collins and Adam Thorsen (of Guruza.com) who are both experienced Rails developers and they had no idea either. I was stuck.

I wanted to launch. Badly. I didn’t want to waste anymore time with this so I picked up a Python book and rewrote the whole site one more time, in Python using the Django framework this time. I had never programmed in Python before and much less used Django. However, the switch was easy enough since Ruby and Python are somewhat similar.

My experience with Python and Django was great; it is a combination every web developer should consider. However, I soon missed Ruby and Rails. Ruby supports “real” private/public/protected methods (Python just fakes that with its naming convention) and it’s syntax is more forgiving (the need for () at the end of each method call in Python was killing me). Django is not as straightforward as Rails, and requires more code to get things done. There are also many little things that don’t “feel right” in Django, like the need to manually pass variables to a view. Data access is confusing at best while Rails’ ActiveRecord is god-sent. These little things really add up.

On the flip side, Python is faster than Ruby and less memory hungry. I was also surprised to actually love Python’s significant indentation (see example). But more importantly, Python and Django just worked! I never experienced weird crashes like I did with my Rails stack.

So, why am I back to Rails for my next project? 3 letters: FUN. I find Ruby and Rails to be pleasant to use. The community large, active and very helpful. The number of freely available Rails plugins and the fast evolution of the core code are also welcomed additions. Rails requires less code, less self.__awkward_method_calls(), has built-in AJAX and REST support, and has much more flexible data access and templating engines.

But what about those crashes? What about the speed issue? Well, I don’t have the crashes anymore. Don’t ask me why, I don’t know, but it’s fine now, I swear! Something somewhere got fixed and it seems to have solved the problem. However, speed is still one of the low points of Rails. Using caching and proper code optimization should take you a long way, though. Matz, the author of Ruby, is working hard on a new virtual machine that should make Ruby just as fast, if not faster than Python.

My recommendation is, try both for long enough to figure out what works and what doesn’t for you. If you are a long-time Python user, Django might be more compelling for you, but if you are coming from a Java, Perl or Smalltalk background, Ruby and Rails will most likely be what you’ll end up using. Either way, I don’t think you can go wrong.

PS: I don’t want to blame Mongrel for my Rails problems because I am still not sure who was the guilty party. Mongrel is a wonderful piece of software and I heartily recommend it. Just make sure you watch it closely if you use Ubuntu on a 64 bit machine.