Ruby Limitations

Replies to This Discussion

Permalink Reply by rob on March 12, 2009 at 11:28am

I am sorry, but with a question like that I can't help but think of what a great philosopher once said..

Donuts. Is there anything they can't do?.
-Homer (as in Simpson, not that other one)

Permalink Reply by Laurence A. Lee on March 12, 2009 at 4:57pm

For what Rails was designed to do (interactive database-driven content on the Web), it fits the bill quite well, and the productivity gains over most other Frameworks is significant.

Rails' Greatest Strength
...comes through its simplicity. Unlike the "Library Soup" of Java, .NET, PHP, and Perl, there is only ActiveRecord as the standard Object Relational Mapper (which can connect to most contemporary databases); there is only ERB as the standard Templating Engine; and there is only Prototype and Scriptaculous as the standard AJAX libraries. For the vast majority of projects, this is enough.

By keeping things simple, new developers can ramp up quickly on the Basics, and they're productive in almost no time at all. In fact, it's so simple, if you're good at writing Schema Specs and Photoshop Mock-Ups, you can outsource the bulk of the work to the Mainland; offshore it to China or India for pennies on the dollar; or even get the work done for FREE by someone eager to get some work experience on a real-world application.

Because there's usually "one Standard Way" in Rails, the results you get from an Outsoured Developer are usually dependable. Outsourcing Rails work is ridiculously cheap today, and it's only getting cheaper every day.

Rails' Greatest Weakness
...also comes through its simplicity. The typical Rails Developer is a "Web Developer on Windows" (or Mac) who doesn't have the first clue when it comes to "Enterprisey" things like Server Maintenance, Process Security, Authentication, or Access Control.

Ask your average Rails Developer to build a Rails Application that manages User Accounts on an LDAP Repository, for example, and most of their eyes will glaze over like a deer in headlights. Sure, it can be done, but that's a minor stretch beyond what Rails was designed for; and if there's no "plugin" available that already does this, the average Rails Developer is really up the creek.

Of course, if you can actually find a Rails guy who can quickly and confidently tie a Rails Application to an LDAP Repository (or anything "Enterprisey" that doesn't involve a single Database), keep their business card at the front of your Rolodex because such Enterprise-Capable people are a VERY RARE breed amongst Rails Developers. They're usually worth every penny of their asking price. :-)

To be honest, I'm dismayed at how many Rails Developers don't care enough about their applications to deploy them on their own servers. Shared Hosting Environments are still quite popular; yet I often see chatter grumbling about the shortcomings of deploying on "X provider". For goodness sake, I wish the whiners would just learn how to administer a Linux Box (or pay the extra for a competent Linux Admin to do so), and avoid all the aggravation of a "Mass Production" McRails-Hosting provider.

Possibly Worse Than Failure
My understanding is that Merb (a competing, yet very similar framework with more ambitious goals) was recently assimilated by the Rails Team, and is going to be the new Core for Rails 3.0. I don't follow the Rails-Core groups to know the intimiate details, but I find this to be unsettling news for Rails in the long-term.

Merb was designed to offer "More Options" out of the box, like using DataMapper as the Object Relational Mapper, or Haml as the Templating Engine. In my opinion, offering such additional options "Out of the Box" in Rails 3.0 will lead to Rails' undoing because (1) Rails is no longer a "Simple Platform" to learn; and (2) other Ruby Frameworks are much better at being "Modular" than Rails can ever hope to be.

Yes, you can use DataMapper and Haml in Rails now, but it's considered an "Advanced Technique" for experienced developers to piece together. Adding "Core Options" to Rails 3 is about as useful (and detrimental) to Rails as Sun's introduction of J2EE to Java 2. It was confusion and elation; but ultimately it opened the flood-gates to the "Library Hell" that most Java Developers face today.

"Swing? Struts? Hibernate? GXT? Applet? Application? Aw hell, why can't there just be a standard way to do stuff in Java?"

That's why I see a lot of Java guys (including myself) ditch Java in favor of Rails in the first place. :-)

Permalink Reply by Ken Mayer on March 18, 2009 at 1:54pm

My $0.02

Sometimes I channel Louis Gossett, Jr, "You want to code Rails Apps? My grandmother wants to code Rails Apps!" :-)

I think the Merb [heart] Rails merge/love-fest will be a win. The key players on both sides didn't need to collaborate; both stacks have loyal followings. They saw more common ground than differences and an opportunity to do more by combining forces. It'll be painful at times, but I think the end product should be better than either parent.

Overall, the big strategic "win" has been the "convention over configuration" philosophy. It makes for very terse code. It also means you have to know the conventions -- which can be disturbing to newcomers: "Wait, who defined this method? find_all_users_by_state -- nobody?!?" Another benefit (for Rails anway) is the "we've made some implementation choices so you don't have to" mantra. It pisses some people off (who think they have a better solution, but don't want to take the time to unwind the choices). Merb took another path. It created a minimalist stack with lots of hooks for components (DataMapper versus ActiveRecord, libxml versus Rexml, etc.) We're all hoping that 3.0 will have the best of both worlds: good choices made for those who don't need to waste time on picking nits, but easy reconfiguration for those that have specific needs to override. There are already some fruits of the efforts with the release of Rails 2.3 (and to a lesser extent the latest Merb release).

I'm not sure I agree that Rails weakness is the lack of enterprisey cluefullness. I'd say that's a weakness of the worker population, especially as the median shifts (sadly) to the left. There're plenty of enterprise class apps out there. Infrastructure admin is a different skill set from application development. Any coder worth his salt should be able to configure a linux box, but sometimes it so much more convenient to let someone do that (over and over again, the old economies of scale thing), and concentrate on the application space. Alas, many, too many projects are too cheap to hire talented infrastructure people.

As for greener pastures... erlang anyone?