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: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: (Score:2)
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.
That's one thing that's always stuck out as unusual and unnatural to me - making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds" (or something, however the syntax works).
It just comes across like Rails tries to make things convenient that were ne
Re: (Score:2, Interesting)
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 wi
Re: (Score:2)
making object hierarchies that seem to serve only to replicate the English language in a language not designed to resemble English syntax.
Not at all required, but that's one of the things I love about Ruby -- that you can do that, which makes the code extremely readable. Whether or not you like the fact that these methods exist on integers, it doesn't really hurt, and at a glance, even a non-programmer understands.
It seems to me like it would be more sensible to have, on a datetime object, some simple 'within', 'before', 'after' methods that return true/false (e.g. post.date.within "5 seconds"
So, instead of adding methods to an integer, you'd be parsing strings? I like the Rails way better.
Oh, and it's a bit more flexible than that -- because 5.seconds is actually a value of time, and 5.seconds.ago is actually a datetime
Re: (Score:2)
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly. Maybe I'm too much of a purist, but clearly-defined modules with clear delineation points between them makes it easy to conceptualize the code.
In Python for example, if I want date/time manipulation, I import the requisite module. Same with threads, process manipulation, file path handling, and so on. In Ruby, it seems as though I get date/time manipulation just by virtue of havin
Re: (Score:2)
Ruby does not stick date/time functionality into integers (or Fixnums, in Ruby lingo). Rails has extended Ruby's Fixnum class to provide methods that convert and operate on dates. It's also added methods to convert 1.thousand into 1000. Since you deal with and compare datetimes SO often when building database-modeled GUI applications, this is a Good Thing in that context. When I write rails code, it's convenient. When I write Ruby code outside of rails, I almost always don't want that.
The amount of ugl
Re: (Score:2)
The amount of ugly, spaghetti-like "meta-programming" needed to make Rails code look as simple and pretty as it does makes me want to scream sometimes.
That's not metaprogramming, that's Rails, or at least, Rails 2. Check out Merb for a counterexample.
Better yet, learn how it works, and then see if you can do better. I remember digging into ActionMailer, and being frustrated at the sheer bloat, but when I wrote something similar (wrote to the database, rather than to SMTP), it was much smaller.
Re: (Score:2)
Re: (Score:2)
Sorry, I guess I wasn't clear...
Yes, it is meta-programming. However, I don't think it's an inherent property of metaprogramming, that it has to be ugly, spaghetti, or convoluted.
My point was that yes, Rails metaprogramming is ugly. However, that's Rails. Metaprogramming can be done properly.
Re: (Score:2)
The spaghetti part is that the integer class handles date/time functions as well. That's inherently messy and conceptually ugly.
If you say so -- keep in mind that not much has to be done within the integer class, other than creating and referring to objects of more appropriate classes. I am not sure if this is actually what Rails does, but it would make sense.
And in that sense, I don't see 5.seconds as being uglier than seconds(5) -- after all, it is unlikely that anyone would create a "seconds" method on integers except for that purpose. Beyond that, I'm sure you will agree, methods like 'ago' or 'from_now' make sense.
There are Tim
Win - win scenario. (Score:1)
Re:Win - win scenario. (Score:5, Funny)
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.
Re: (Score:2)
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.
Well then I'm excited.
Re: (Score:2)
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.
They're not breaking down silos. They're just building a bigger silo.
Re: (Score:2)
Why do you say that? Making an effective release of any platform is no easy task.
It seems easy with the exponential growth that Rails saw in the past, because you don't have to care about the existing users. Just break everything, whenever you want, there are plenty of new users. You don't care if a library has bugs in it, because users are starting from scratch, so they'll just be happy it does anything at all.
Now, with adoption growing at some more reasonable pace, they'll need to satisfy existing users.
Rails community grows up (Score:3, Insightful)
Re: (Score:3, Insightful)
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 th
Good lord, what is with the taggers? (Score:4, Interesting)
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.
Re: (Score:2, Insightful)
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: (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: (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: (Score:2)
It also allows you to use Enterprise Ruby, with it's COW GC.
This is something Merb is likely to support out of the box, soon, if it doesn't already.
Re: (Score:2)
> is Passenger easier to deploy?
It's easier because you can replace a mongrel cluster with mod_passenger which dynamically configures the cluster size. Kind of like you configure an Apache web server - you don't set it to have 10 instances running all the time, instead you set it to never exceed 100 process and let Apache manage how many processes it needs under that maximum threshold.
But you're right - the actual deployment is still done with Capistrano, albeit with some minor tweaks [blogs.com] to the deployment
Re: (Score:2)
I see...
So, Passenger won't be needed as soon as Merb completes its own, similar project. It is already able to fork, which is especially useful in development mode, and there has been talk of having it fork on demand, to dynamically scale your cluster up and down.
That's good, because Passenger is a little too tied to Apache for my tastes. I much prefer a pure-Ruby solution which I can throw behind any old load-balancer.
Re: (Score:1)
> I much prefer a pure-Ruby solution
> which I can throw behind any old load-balancer
Right on, yup, that sounds better to me too. But, for now, Passenger is a vast improvement over mongrel_cluster.yml and all that.
Re: (Score:2)
> Either the taggers got up on the wrong side of bed today,
> or my general impression of Ruby is horribly wrong.
Quite so. For my military reading list [militarypr...glists.com] site, Rails is awesome. Plus Sphinx for searching, of course.
Re: (Score:3, Interesting)
I just finished my first rails project, a caption contest [mypalmike.com]. Took about 3 days to implement. OK, yeah, the ugly html layout sucks at the moment, but the backend functionality works pretty well considering the time invested.
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: (Score:3, Interesting)
Speaking of which, why won't Slashdot let me turn the tags off?
Re: (Score:1)
There's a preference to ignore Idle stories on the front page.
Re: (Score:1)
Stick this in your userContent.css:
Re: (Score:2)
Thanks. I hadn't thought about outright blocking it.
Re: (Score:1)
Re:Who cares (Score:4, Insightful)
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.
Re: (Score:3, Interesting)
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'.
Re: (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 wi
Re: (Score:2)
We were running as CGI to debug problems between Apache and mongrel. Turned out it was the rails app causing our grief, but that led into my debugging issues. I had almost nothing in log files to tell me what was going on.
But strace was a big help when I tried to run as CGI. The problem was not log/ and tmp/, but more like rails (or ruby) doing over 20k file lookups all over the system looking for various files. On a local disk, that can be pretty quick. Over NFS, that large number of searches really b
Re: (Score:1)
Yes, it has changed a lot in the past few years, but it has only been around for four years and took time to mature. Deploying it has not been that difficult for a while now in a dedicated environment, and with Passenger (mod_rails) it is ridiculously simple even in a shared environment. Running Rails apps via CGI has not made sense for quite a while, even if you were using Fast CGI, Mongrel and a load balancing proxy have performed better and been easier to set up for quite some time.
Also, I'm not sure e
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: (Score:2)
There's little to no debugging
Doesn't sound like a sysadmin, but I'll bite.
Yes, the debugging does kind of suck. On the other hand, Rails is pretty easy to test. I do still occasionally break out the debugger -- which does exist, and isn't actually that bad, just isn't good -- but for the most part, unit tests work well enough.
we've gone through four different ways to run RoR apps
And they do seem to be improving... Right now, Rails apps are generally run as a standalone webserver, which can (if needed) be placed behind a load-balancing proxy like nginx, making it easy to scale horizontall
Re: (Score:2)
What exactly are you trying to debug? As for deploying new versions, It's dead simple to bundle rails with the application, and then all you are doing is an application deploy.
I'm trying to track down problems that the coders are having. We're not sure if the problem is in the RoR end or the Apache/mongrel end.
Why were you running as a CGI in the first place? Did you do any research before hand? I don't understand how you would do any reading about ruby without stumbling across it's relative slowness, and then you tried to add another layer to the process? And then you add NFS for good measure?
Rails is optimised for developer productivity, not for raw execution speed. As a sysadmin, you need to run it with either a pack of mongrels or phusion passenger. If you're debugging for more than 15 minutes per deployment, you need to get your developers to write some more unit tests.
Why as CGI? Like I said above, we're trying to debug problems. The response that Rails developers have to problems is pretty poor. And to add to that. mongrel isn't being developed anymore (from what I'm told), and mod_rails is the new hotness. Running separate servers for each RoR app just won't cut it - there's too much that requires interaction between the developer
Re:Who cares (Score:5, Insightful)
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!
Re: (Score:2)
How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.
If anything, I think the presence of "all" in "Orders.all.each { |order| ... code goes here ... }" is much easier to spot than a missing SQL clause.
Not that that excuses any of Rails' other flaws that you pointed out.
Re: (Score:1)
You're just wrong. Order.all is simply an alias for Order.find(:all), and as such and array of Orders - *not an associations*. (see http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001966 [rubyonrails.org]). There's no N+1 problem here.
p.s. I just noticed the grandfather quotes code in the form Orders.find. This is clearly a sign the author isn't even used with basic Rails naming conventions.
Re: (Score:1)
Re: (Score:1)
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.
So what's Ferret or you inability to manage system services got to do with Rails ?
Not to mention that it's easy to do something idiotic in Rails. For example:
Orders.all.each { |order| ... code goes here ... }
With power comes responsibility - something you ought to know by now. You can do something just as stupid using _any_ other web framework + ORM; this is not a problem in Rails, it's a problem with the way you choose to solve the pro
Re: (Score:2)
I can manage intelligently-designed services, but services that are designed with no regard for sane UNIX behaviour become tricky. I can work around them, but people shouldn't have to do extra work every time they deploy something if this could be solved by sane design considerations in the first place.
Likewise, I'm not going to 'fix' rails because I'm not a Ruby developer, I'm a sysadmin. My job is to get Rails running on test and production servers, and in that regard Rails is a huge hassle, far more than
Re: (Score:2)
Oh, I failed to mention that we had looked at mod_rails (Passenger) and it looks completely awesome in the context of Rails websites that are capable of running on a single machine. Unfortunately, our site is such that more machines are required, at which point it's actually easier to run multiple machines with multiple Mongrel processes than to run multiple machines with multiple Apache processes, ironically enough.
It may actually be more sensible to rearrange our architecture to attempt to take advantage
Re: (Score:1)
Re: (Score:1)
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.
Well, Ferret is not a "common service" anymore. Most of people already switched to Sphinx. I had horrible experience with Ferret myself, and I wouldn't say it's reliable. It's not even developed anymore. The thing that you mention Ferret in this context just confirms that you don't have much experience with Rails. It's not a standard Rails feature, it's a 3rd party addon. You don't judge framework by quality of addons, just like you don't judge operating system by quality of programs written to it.
Re: (Score:1)
Or if you want more scalability, spead and general coolness you can use JRuby (with Warbler) to deploy a Rails application on a J2EE application server of your choice (e.g. Glassfish, Tomcat, Websphere). This also allows you to leverage technologies such as JMS or JDBC connection pooling from your Rails application.
Deploying Rails application has been a mess since it's inception,
Re: (Score:2)
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'.
Anyone running a performance-sensitive webapp over NFS as a CGI application doesn't know what they're doing. Regardless of the programming language.
Re: (Score:2)
Go read my other comments where I explain what I was doing, why, and why the performance was so terrible.
Perl CGI doesn't have this problem, nor does python.
Re: (Score:3, Funny)
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.
Re: (Score:1, Informative)
Goto pragprog.com and order the Beta of the 3rd edition.
Really great news (Score:3, Interesting)
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.
Doh. (Score:2, Interesting)
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'm more than a little worried.... (Score:1)
I didn't switch to Merb primarily for technical reasons; I switched to Merb because I got tired of being insulted whenever I asked for help on #rubyonrails (my very first experience there was being told to go back to Perl if I didn't understand Ruby (note, not if I didn't _like_ Ruby, if I didn't understand it), and my last was being told to 'drop the gimme gimme gimme attitude' when complaining about something that wasn't documented -- _AND OFFERING TO PROVIDE A DOCUMENTATION PATCH IF SOMEONE WOULD HELP ME
The curse of hype... (Score:2)
Ruby on Rails has a great community, but the only ones (with few exceptions) hanging out on #rubyonrails are newbies and/or fanbois.
It was long ago that the pros left the places where newbies also could hang out and ask questions. There are a couple of half-anonymous invite-only communities where hundreds of already semiprofessional Railsers (including core developers of Rails, major sites and plugins) hang out and help each others and life there is great and very friendly and helpful.
Unfortunately that als