Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Programming IT Technology

Rails and Merb Ruby Web Frameworks Merge 80

Posted by kdawson
from the flattened-red-gem dept.
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."
This discussion has been archived. No new comments can be posted.

Rails and Merb Ruby Web Frameworks Merge

Comments Filter:
  • by spinkham (56603) on Tuesday December 23, 2008 @05:14PM (#26216805)
    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.
  • by Anonymous Coward on Tuesday December 23, 2008 @06:15PM (#26217459)

    Every technology has it's haters. Especially when it comes to web. Any post about PHP is bound to have the phpsucks tag. Java, Flash, etc. have their own hate tags too. PERL is pretty much the only one with sufficient amount of fanboys here to avoid any negative comments...

    But in the end tags are never about consensus. They are about the consensus of the loudest people. If such people were smart and knew what they were talking about, democracy would have made the world perfect long ago.

  • Re:Who cares (Score:4, Insightful)

    by Allador (537449) on Tuesday December 23, 2008 @07:18PM (#26218039)

    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.

  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Tuesday December 23, 2008 @08:14PM (#26218517) Journal

    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.

  • Re:Who cares (Score:5, Insightful)

    by Sentry21 (8183) on Tuesday December 23, 2008 @10:28PM (#26219337) Journal

    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!

"There is nothing new under the sun, but there are lots of old things we don't know yet." -Ambrose Bierce

Working...