James Britt has this to say on the Rails/Merb merger:

Because Merb was essentially (as best I could tell) a variant of Rails (with ideas from Nitro, Ramaze and other frameworks), it seemed easer for ideas to trickle back and forth between Merb and Rails. Rubyists had more options, and both Merb and Rails could feed off of each other. It seemed a win all around to have them independent.

The consolidation removes this useful competition. This is maybe a plus for folks who prefer Rails, and a gain for people who want to do things the Merb way but can now say they are using Rails. Less useful to people who want to see more distinct options.

That’s exactly what I worry about. In the larger world, though, I don’t expect this to be a huge detriment. The MVC framework market is vast and varied, and there are plenty of good ideas being generated all over the place.

The Rails team has just announced that Merb, an alternate MVC framework for Ruby, is being merged into Rails 3. Given some recent angst about the splintering of the Ruby Web development community, this is probably good news. I haven’t used Merb, but I was all for more competition. In the open source world, the best developers steal every good idea from their competitors anyway. Between this announcement and the announcement of Rails Metal, it’s looking like the end of year trends in the Ruby Web development community are toward harmony.

My number one point of frustration with Ruby on Rails is that as easy it as it is to build Rails applications, it’s a big challenge to get them deployed properly (mainly due to lacking documentation for Capistrano) and to keep them running happily.

I have a simple Rails application that I’ve deployed using Apache and Mongrel, with three Mongrel processes. When I looked at top this morning (it had been running awhile), it was consuming over 500 megs of RAM. My first thought was, of course, “memory leak”. I restarted the app, and the ”mongrel_rails” process was consuming only 32 megs of RAM. I’ve since watched it grow to 45 megs of RAM consumed. That appears to confirm my suspicion that something is leaking memory.

What’s next? Finding the memory leak. The problem could be a bug in Ruby, Mongrel, the Ruby on Rails gems, any other gem I’m using, or my code itself. At this point I need to sift through the next steps and start experimenting. The options from here are:

1. Start upgrading pieces of infrastructure for which new versions are available.
2. Instrument the application and try to figure out what’s leaking memory.
3. Try to reproduce the problem locally so that I can experiment in a safe environment.

I’ll let you know how it works out.

While I enjoyed developing this application using Ruby on Rails, the amount of infrastructure required to keep this relatively simple application up and running frustrates me a bit. Had I written this application in PHP, I might have two dozen files in a directory running under the versions of Apache and PHP that were bundled with the server’s Linux distribution. The odds of running into a memory leak in that kind of environment are really low, especially with an application as simple as the one I’m dealing with.

With Ruby on Rails and its relatively immature infrastructure, the administrative overhead is higher than it would be for many other types of applications. The complexity of the Ruby on Rails infrastructure also explains why Ruby on Rails is unsuitable for shared hosting.

The takeaway from this is that there’s more than speed of development to take into account if you’re deciding whether to use Ruby on Rails to build an application. You also need to determine whether you have the administrative cycles you need for the care and feeding of a Ruby on Rails application.

Update: The first thing I did was upgrade Rails from version 1.2.3 to 1.2.6. We’ll see what effect that has on the memory leak.