For the past few weeks I've been kicking the tires on the Ruby language and the Rails framework. This post is not meant to be a review of either, but I thought I'd note some of my impressions for other .Net developers that have been hearing the buzz and have not had the time to take a look.
First of all, I'm not planning to make a jump from ASP.Net to rails anytime soon. However, I think there is always benefit in exploring other technologies, approaches and points of view and my look at these things was primarily motivated by curiosity.
The Ruby Language
I love this language. Scott Hanselman has commented on how easily intent can be expressed in Ruby and Wilco Bauwer likes its rhythm. Writing logic in it feels really natural, to me, and it seems that whenever I need a particular piece of functionality, it's available and easy to invoke without having to jump through hoops. Without casting a vote for either dynamic languages or statically typed ones as the be-all-and-end-all, I have to say that if I were to be tasked with creating a domain specific language I'd certainly go for Ruby as my language of choice to implement it in. It lends itself well to that type of exercise. After all, to an extent Rails is a DSL for the web application space. Some day to day tasks would lend themselves well to being implemented in Ruby. Command line tasks, in particular, could be easily handled in Ruby. The language (as implemented for Windows) supports calling into the win32 API and COM. It does not contain any support for building windows UI, though you can do that by calling the windows API (if you're nuts) or by making use of one of the many Ruby .Net bridges that are freely available. Just don't expect the performance of the bridge to blow you away.
Another thing that impressed me was the number of dynamic language features that are making their way into .Net languages. Anonymous methods, continuations and extension methods all seem to have their roots in dynamic languages such as Ruby.
Ruby is easy to learn and the code is easy to read.
As one who appreciates the value of convention and likes having a process in place to grease the wheels of progress, I find Rails to be a very comfortable approach to use for web development. As stated on many Rails-Centric sites, Rails is about "Convention over configuration" and "DRY" or "Don't Repeat Yourself" meaning don't duplicate code. Typical frameworks offer abstractions to make the most commonly required functionality easier and faster to use. Rails does this well, but adds code generation and a type of adaptability that could only be achieved by using dynamic language such as Ruby. There is also a substantial number of tools to aid the developer with ancillary tasks such as deployment and testing. In general, Rails forces the developer to use the Model-View-Controller pattern to build their web application. Few would argue with this approach. ActiveRecord, which is an ORM library, is used for database access. ActiveRecord is the stated inspiration for the Subsonic library written in .Net and greatly simplifies database access.
Many proponents of Rails claim extraordinary gains in productivity can be achieved. I can see how productivity can be increased greatly for an experienced Rails developer, but be warned that there is a lot to remember and new Rails developers may find they are spending a great amount of time in the Rails documentation.
There are a few IDE's out there that support Rails development. I preferred RadRails and have been using it for the past few weeks with good success. I found that Rails, as many have claimed, brought some fun back to the development of web pages.
The one area I found to be a significant pain was in the deployment story. Rails is not thread safe. This means that each web request cannot be handled by only a new thread, but a new process. I searched, for some time, and found some solutions using FastCgi which basically spins up several instances of a web server and feeds requests to them. There seem to be some better solutions on the horizon , but I was not able to find what I would consider to be a "clean" solution to use immediately.
I've gained a number of insights, so far, from this exercise. I don't see myself building my next business application in Rails (but, who knows) or even being gainfully employed as a Rails developer, but the lessons learned will continue to open my mind and make me a better developer.