Rails and Merb Ruby Web Frameworks Merge 80
An anonymous reader writes "The Merb and Rails Core Teams today announced a major merger; the two projects will become one, and be released some time in Q2 of 2009 as Rails 3. This is great news for lots of folks who worried about the potential community fracture, as well as great news for all the developers who will now have an all-around better option for programming Ruby. Read more about the details in Yehuda's blog post, or at the Ruby on Rails blog."
Re:WTF (Score:4, Informative)
Merb is like a lightweight RoR. Lightweight because it's more optimized and leaves more decisions up to the end user (as opposed to RoR's one size fits all). Ruby on Rails v3 will be more modular so if the shoe fits, you wear it. But everyone else can replace the parts they don't need or want.
Re:Good lord, what is with the taggers? (Score:4, Informative)
> the backend functionality works pretty well considering the time invested.
So true. I think Rails (especially when combined with Passenger) really lowers the bar for getting a dynamic web site with readable URLs (e.g., /captions/public/posts/4/entries/new [mypalmike.com]) up and running. It opens a lot of doors; good times indeed!
Re:Who cares (Score:3, Informative)
I agree that there are lots of gotchas in your first few deployments before you learn all the unwritten rules.
Nowadays though, its not much different than deploying a PHP app, using mod_rails/passenger.
svn up your changes (or capistrano or whatever you like), then touch tmp/restart.txt and thats it.
It's not quite to the level of simplicity of PHP, but it wont take long.
For real fun, try running a Rails app where it's deployed to an NFS filesystem and then try to run the app via CGI. You can see how well it's 'optimized'.
I'm not entirely sure what you mean here, other than you're obviously frustrated with the platform.
I've never tried to run a rails server with the app content on a network-mounted filesystem, but I have done that with assets (images, etc). And I'm not sure why you would ever run Rails via CGI, unless this was several years ago, predating mongrel.
I could see that its possible certain parts of the app folder structure may not play well with NFS, but you could keep those on a local fs (ie, everything under log/ and tmp/).
Were you running a cluster for example, with all of them mounting the same app filesystem for simplicity? If that were the case, each server would almost certainly need their own local tmp/ and log/.
Re:WTF (Score:4, Informative)
It's also been lightweight in that Rails has always had everything you need, in some form. All kinds of Rails plugins that won't work with Merb. All kinds of conveniences that you get for free somewhere in ActiveSupport, like being able to type "5.seconds.ago" or, of course, Symbol#to_proc -- some might exist in Merb, some won't.
This move is good for Rails for obvious reasons, like the ones you've outlined -- even just ActiveSupport takes something like a half second to load on my machine. But it's also a good move for Merb -- probably the single biggest problem Merb had, for many people, was "it's not Rails."
Re:Good lord, what is with the taggers? (Score:3, Informative)
You're absolutely right that Ruby is slow, and Ruby 2.0 will make it faster. But relative to what?
It turns out, someone has done benchmarks [slideshare.net], and the results may surprise you. It turns out, Ruby really isn't that slow.
As for the ease of deploying, you can do it seamlessly with mod_passenger nowadays
You know, I really don't get this -- how, exactly, is Passenger easier to deploy?
For that matter, how is Rails hard to deploy? I've always found Capistrano to be much easier (and more powerful!) than sending PHP files over FTP.
Re:Good lord, what is with the taggers? (Score:3, Informative)
Passenger is crazy easy to deploy. It also allows you to use Enterprise Ruby, with it's COW GC. It's a much better deployment strat. than a pack of mongrels in my extensive production usage. Your mileage may vary, but I doubt it.
I currently run a lot of sites both ways. Nothing wrong with either. But my passenger deploys are simpler (I have a single cap script that also sets up my vhost, reloads apache...basically puts the site live in one step. This was a ton harder in mongrel setups.)
Re:Who cares (Score:5, Informative)
For debugging, New Relic provides some awesome tools that allow introspection of delay and timing at a function dispatch level. If you're serious about Rails, New Relic is for you.
As for file-backing your Rails app, my company [engineyard.com] has had huge success with GFS. It can be a beast to maintain sometimes, but it will crank out the IOPS behind very hungry RoR apps fairly well. It also requires shared block devices, though, so it may not be for you. The S3 plugins for Merb and Rails also go a long way to scaling everything but the code itself (which should be manageable on even the surliest NFS deployment).
We've done some really good work with Rails deployment. There are a ton of ways to deploy it, but I think that is more reflective of the variance in people's deployment requirements more than anything else. Phusion's Passenger and Engine Yard's deployment work are helping to lay down best practices here, and we'd be glad to talk to you about smoothing out the deployment process.
Rails is definitely a good application for teasing out some of the pathological behavior in NFS, but that's not necessarily a bad thing about Rails. It's already used by some to test the pathological niches in new Ruby releases (e.g. "Does it pass the Rails test?").
Working with Yehuda and Ezra on a daily basis, I can safely say that you can expect to see a lot of attention to performance and refactoring some of the cruft that has inevitably popped up in Rails' large codebase. DHH has a great vision and Yehuda has great attention to detail. I don't want to imply that "Rails needs Merb" or "Merb needs Rails", but I expect some really good results from the collaboration.
Re:oh ffs... (Score:1, Informative)
Goto pragprog.com and order the Beta of the 3rd edition.