A Cloudy Future for Ruby on Rails

I think that the long term (read, ten year) future of RoR is cloudy, but the near term is likely to be quite good.

First, while Rails might have some scaling and performance issues for really big sites, there really aren't that many really big sites out there. For the really fat "long tail", where sites (like Omninerd) have much more typical traffic loads, the scaling and performance issues are moot. A much more important factor is the ease with which one can implement and deploy new features.

I've been messing around with RoR for a few months, now, and have started deploying some real-world applications. The combination of Ruby and the Rails library are a vast improvement on earlier technologies.

One of the major new trends I see happening in the industry is the idea of "domain specific languages". It's still just beginning to pick up traction, but I think it's ultimately going to have a big impact. There are two approaches to DSLs - you either end up writing your own compiler or interpreter for it, or you build what's called an "embedded DSL". It's far less work to do an eDSL, since the basic framework of computation (loops, expressions, branches, and so on) are provided by the host language. But a lot of popular languages are rather weak for doing eDSLs, because their syntax is a bit too rigid. EDSLs in Java, for example, are much less satisfying than eDSLs in Ruby or Haskell. Ruby's syntax is very friendly for eDSL-like extensions.

Ruby has also borrowed some important ideas from the functional programming paradigms. I've already mentioned elsewhere on the site that I'm a huge fan of functional programming.

The most noticeable feature Ruby has borrowed from the functional paradigm is the "closure" - what Ruby calls a "block". The basic idea is to be able to describe a piece of computation that can be then passed around and manipulated as if it were an ordinary value, like a number or a string. Rails makes very heavy use of closures in creating an eDSL for building web sites.

The result, together with the Rails philosophy of "programming by default", allows one to put together relatively simple web sites in very short times. Where the typical tutorials for putting together a small e-commerce or blog site using JSP or ASP or even PHP normally require several sessions of work, the equivalent tutorials using RoR typically have a working, usable site up in a single session.

Zed Shaw's complaints weren't actually against Rails. If you read his rant, he's mostly complaining about the Rails community, who he feels didn't give him the respect he deserved. Some of his technical complaints are valid, though, and if Rails is going to have long-term viability, the community will have to address them. That they end up solving them differently than Shaw would have them do it isn't nearly as important as actually solving them.