Slashdot Mirror

This is why I think working in the opposite way to Rails - designing your data model in terms of classes and letting the ORM product generate a schema from that (still DRY, but in the other direction) makes far more sense - I can move my apps between those databases with no effort at all.

If you want to do web apps in ruby in that style, you should try Nitro + Og.

Ruby's ugly second cousin, twice removed.

See Nitro web framework for a better framework than RubyonRails. Also see the Og project on the page, a competitor to ActiveRecord.

Long live opensource!

Rails is OK. It's a great way to get into the language and attract users, and for that I appreciate its existance.

That said, as a fairly long-time user of Ruby myself, I wouldn't use it. Many of the features it provides are more academic proof-of-concept implementations than well-tested, well-polished ones. It requires you to do a lot of things manually that could easily be done automatically, and you still write bits of SQL in your code. Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface. This is bad for any number of reasons. Finally, it's pretty much tied to MySQL, so if you use PgSQL or Oracle (and you should), then you're in for a big headache.

That said, if you're interested in Ruby and/or Ruby on Rails looks cool to you, check it out and play around with it. It's also not the only thing that ruby provides to develop applications, even web applications. If you're developing a more serious app, you may look at stuff like PageTemplate for the frontend, ObjectGraph for your ORM, and soap4r for services.

So regardless of your stance on Rails, check out Ruby... there's a lot of cool stuff.

Rails isn't the only Web app devel framework that Ruby has... It's just that Rails is getting all of the attention. Some folks prefer Nitro over Rails.

There is no downside to using ruby on rails. Closest thing to a silver bullet since the web came out.

There are several significant downsides to using Ruby on Rails.

Firstly, the way that ActiveRecord works by default - generating classes at run-time based on database tables - is considered by many (well, me at least!) to be a very backward step, as it makes code vunerable to changes in those tables, and also makes portability of code between different databases non-trivial. There are far better ways to do this - the Python ORM Dejavu (in in which the data model is expressed as classes) is an example. Almost all modern development languages work this way - with the exception of RoR!

Expressing the data model as classes can be done using Og (or Nitro+Og), and I believe that Og can be used as an alternative interface to Rails with just a bit of work. However, Rails does this (mostly) the right way, since your data is always more valuable than your application. Where this approach falls down is based on a couple of things:

1. Rails uses MySQL as its “correct” database. MySQL is not and never has been good, just ubiquitous. There are some very broken concepts in ActiveRecord because of this assumption.
2. Migration is difficult, as it is done externally to the application.

People who don’t really know anything about data modelling and relational theory tend to prefer class->table interpretation. People who understand data modelling tend to prefer table->class interpretation. There’s room for both, but the preferred method—and the more portable method—is to treat the database as the authoritative model for the application, not the other way around. (Yes, reading the database model is more portable than creating the database from the application. Especially with a dynamic language like Ruby.)

Secondly, Ruby is slow. There may be future JIT systems that help deal with this, but they are not there yet.

This is a straw-man. Ruby most emphatically is not slow. It is also not the fastest performer. But for what RoR does, it is generally fast enough. If you’re using the MySQL adapter, you definitely want to make sure that you’re using the native adapter, not the pure Ruby adapter. I’m developing one of the more complex applications/libraries in Ruby (PDF::Writer) and while I won’t pretend that it’s a speed demon, it’s impressively fast for what it does do, complete with rollback for the layout handling. Ruby’s performance is more than adequate for most applications, especially most database-backed web applications.

Thirdly, Ruby is changing, and it is likely (from what I read) that the next version will not be fully compatible, so any major project developed now in Rails will have upgrading issues.

Probably not. I suspect that there will be 80% or more compatibility, based on the currently submitted RCRs that have positive response. I also expect that the RoR community will make sure that Rails runs well on whatever the current version of Ruby is. I believe that some work has been done to make sure that RoR works well on Ruby 1.9, which is the test bed environment for most of the syntax changes that will be coming with Ruby 2.0.

So Ruby on Rails is very far from a silver bullet. It may a neat way to get small (in terms of code) websites up quickly.

I agree with your first sentence. I disagree with your second, at least partially. RoR—and Ruby in general—makes a lot of code smaller and easier to maintain. Ruby isn’t the

Nitro; another Ruby web framework which seems stronger than Rails in some areas.

Mmmmm, so much choice.

I don't see how consistency in behavior and interface actually preclude anything, especially to those more familiar with the language. It is a Good Thing(tm) to be consistent, even if it means the language is still accessable to "the uninitiated." In fact, it makes someone already familiar with the paradigms more productive, because they have to look less stuff up, and have a clear idea of what to expect.

Look at Ruby's Og (which is in the same vein as tied hashes):
http://www.nitrohq.com/view/Og

Yes, it does some interesting things, but the interface to it doesn't have to be strange.

If you love Ruby (and why wouldn't you), there are more alternative web frameworks. Have a look at Nitro (http://www.nitrohq.com/ and the Og object relational mapping library. Nitro, in true Ruby spirit, gives the developer choice, instead of enforcing the design of the application or specific patterns. And Og is a completely oo solution that transparently maps Ruby objects to sql (or non sql) stores and not vice versa.

The future is here.
Django is now old news...

Yeah, Nitro is in Ruby. But considering that RoR has opened the Ruby door so that many people have been learning Ruby lately ( and also considering that it's quite easy to go from either Perl or Python to Ruby) that's not a problem. Excellent Ruby web programming frameworks are now popping up like mushrooms after a Fall rain.