Slashdot Mirror
Rails and Merb Ruby Web Frameworks Merge
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."
Either today is April 1st.. (Checks calendar). Nope. I guess Rails is no longer a ghetto. (Sorry Zed) The rails and merb teams collaborating on making a good project... It just brings tears to my eyes to see these boys grow up and play nice.
Blessed are the pessimists, for they have made backups.
Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.
I agree. They can really leverage synergies and break down some silos with this.
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.
Do you even lift?
These aren't the 'roids you're looking for.
At time of posting we have:
Either the taggers got up on the wrong side of bed today, or my general impression of Ruby is horribly wrong.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Ridiculously fast development time. It's insanely productive for the 80-90% cases that you run into.
Really nice schema/db migrations system built in.
Ridiculously simple to take a web app built with it using standard postbacks, and make it all super-fancy ajax, in-place-editing, and lightbox goodness.
Ridiculously easy to turn the whole thing into a REST engine for some other front-end or machine-to-machine usage.
My (un-quantified) perception is that its running about 1/3 the size (lines of code) of a similar php app, and even a smaller percentage compared against asp.net/java.
For a certain segment of app development needs, its really quite compelling.
Depending on who you ask, it's either to make good web developers more productive, or to make idiot web developers marginally productive. As an idiot web developer, I can only vouch for the latter. But I must say, I do love me some Rails.
You want the truthiness? You can't handle the truthiness!
It may be easy to write and deploy, but as a sysadmin that builds the systems that run RoR apps, it stinks.
There's little to no debugging, we've gone through four different ways to run RoR apps, and there are new versions every few weeks.
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 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/.
This will give the Merb people a lot more momentum, and their project will have a really big community, a thriving job market, and lots of books written about it.
And it will give Rails the value of all of the good stuff that Merb brings to the table -- Rails will be more modular and less monolithic, easier to learn, and easier to move forward because people will be able to split off smaller pieces and improve them.
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."
Don't thank God, thank a doctor!
Python started in 1991, Ruby in 1995. Are you telling me you're still mad about that?
Or are you talking about something of substance -- like, say, frameworks? Because here, Merb has done some things that make Django developers jealous. (And vice versa, of course.) And Python still hasn't figured out how to write a decent package manager -- "easy-install" is anything but.
And your "performance" comment, as it turns out, really isn't justified. I don't know about Python, but it turns out that Merb is faster than PHP, and absurdly faster than CakePHP.
Don't thank God, thank a doctor!
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 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.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
Hmmm. Merb was awesome because it was a lighter, faster, less bloated Rails. I'm not convinced that merging the two will result in anything other than dragging Merb down to Rails' level.
I'll second this. Deploying a RoR app for a (reasonably large) website, I've seen all manner of issues. We're proxying to Mongrel on the backend, but it's a huge hassle.
It's been a rollercoaster ride of excitement, as each new feature, daemon, or cronjob has required not only programming by the developers, but hours of time spent by me writing shell scripts to wrap Ruby scripts because the framework either doesn't allow for something, or does it in a silly way. Rails devs/users will argue that 'You can do [x], just do [y], [z], and [q], and voila,' but I'd prefer things to be straightforward, rather than what seems to be ad-hoc design-philosophy-of-the-week.
Maybe I'm just frustrated, but it seems like the Rails devs develop in a vacuum, ignoring the practical concerns involved in actually *deploying* code. I always stumble across blogs with long explanations and tutorials on things so simple as *starting a service at boot* - and not even an arbitrary service, a common service like Ferret. It almost reminds me of qmail, famous for doing things its own way, even if that completely goes against everything else everyone else does.
Not to mention that it's easy to do something idiotic in Rails. For example:
Orders.all.each { |order| ... code goes here ... }
Simple task - iterate over each order and run code on it. In practice?
End result is that code that works fine on your test machine (with a hundred orders) fails miserably on the live DB (with several hundred thousand), crashing the server by allocating all the memory available. We also found that Rails (the framework itself, not our code using it) was leaking huge amounts of memory, upwards of 14M (yes, megabytes) per request in some instances, and the GC seemed incapable of cleaning up.
I've dealt with a lot of systems, and I hate PHP more than anyone, but Rails is just full of pitfalls, gotchas, and 'magic' (where it tries to be clever for corner cases at the expense of clarity or efficiency in all cases). It's ugly, bad, and wrong in many situations, and I look forward, honestly and truly, to the excellent Merb developers and what they can do when given their time in the spotlight.
Go guys! We're counting on you!
Agreed, but note that it's rails that adds the date/time functionality, not ruby. While I think it's great that it's *possible* to change the behaviour of core classes, this should be done with extreme restraint, and rails seems to have gone a bit overboard with it.
Be wary of any facts that confirm your opinion.