Why should I use Ruby on Rails

rubyonrails-talk
1

This is the right forum.

This is trivial to do in RoR.

The benefit that you get is that you can have a production ready product in a fraction of the time that it takes you to write a deployment descriptor in almost any other platform.

The program that you want is almost right out of the Agile book - as the main example.

Given that programming is 90% research and 10% coding, you're in trouble if you don't have time to do your own research. On the other hand, soliciting input from more experienced developers is a form of research. The problem is that the answer will be biased.

I disagree with my colleague's comments about "pesky </tag>'s". Redundancy is necessary in any wire protocol, such as SGML (of which HTML is a small subset). Since SGML is generic in nature, with no knowledge of the intended contents or business of the transmitted document, ending a <tag> with a </tag> is a clean notation that allows the expression of any simple or complex data structure and keeps the interpretation of data separate from the data itself.

With that said, Ruby is bult around small-system concepts and Rails has a lot of My-SQLisms. There has been some difficulty getting the Ruby community to understand the benefits of things like prepared statements. Building a transactional system is a bit (not a lot) more difficult than I had expected, so scalable real-time systems that pass the atomicity test require a bit of coding.

PHP has the same sorts of flaws, and is painful enough to understand that I have never actually learned it. It grew organically, so the syntax is irregular. It has most of the same small-systemisms (can I invent that word? please?) that Ruby does.

Does this help?

2

Really? Please do elaborate. Are you working with distributed transactions, or..?

Isak

3

Elaborate on which bit?

Prepared statements - It was always considered a truism that 85% of the time spent in a Rails App is in the database. Since Rails generates its SQL on the fly and submits it new every time, it has to repeat the work of the "prepare" every time. When I questioned this, I was told that "not all RDBMS's support prepared satements".

The RDBMS one of any note that fits that description is MySQL. Even MS-Access has the concept, even if it is implemented oddly.

In direct measures, 50 to 85% of the time that dynamic SQL is processed centers on the prepare phase. Use of a prepared statement has this overhead once, then only the time in wire communications and actual execution thereafter. An obvious and painless performance enhancement would be to use prepared statements over SQL strings for the bulk of Rails' transactions.

A couple of people on this list have done so and publised timing results, showing that Rails benefits spectacularly from the use of prepared statements.

An additional but less important boost comes because, when using a prepared statement, only the handle (an integer ususally) to the statement and the parameters cross the wire on execution. Finally, prepared statements offer a level of security and eliminate the need for the overhead of the "sanitize" method that tries to prevent string substitution attacks on every SQL invocation.

With all of these benefits, the resistance to adopting prepared statements was very surprising to say the least. For the most part, the arguments against it were "MySQL doesn't do prepared statements yet, so Rails won't"

Small-systemsisms - for starters, see above. On large systems, efficiency is important because you pay by the CPU cycle. Anything that is a performance drag is also spending real dollars. A rails front end, because it replicates the expensive work of the SQL prepare on every call, is expensive to operate against a large-systems back end.

Scalable transactional systems - see above. I could dig out more examples, but this one example shines.

Does this help?

4

Hi --

I disagree with my colleague's comments about "pesky </tag>'s". Redundancy is necessary in any wire protocol, such as SGML (of which HTML is a small subset). Since SGML is generic in nature, with no knowledge of the intended contents or business of the transmitted document, ending a <tag> with a </tag> is a clean notation that allows the expression of any simple or complex data structure and keeps the interpretation of data separate from the data itself.

SGML actually allows unclosed tags, though, as long as it can be inferred unambiguously (from the DTD) where the element ends. XML makes you close every tag, which, along with the notion of "well-formedness" and having DTDs be optional, makes it much easier to write parsers and processors for it.

With that said, Ruby is bult around small-system concepts and Rails has a lot of My-SQLisms. There has been some difficulty getting the Ruby community to understand the benefits of things like prepared statements. Building a transactional system is a bit (not a lot) more difficult than I had expected, so scalable real-time systems that pass the atomicity test require a bit of coding.

PHP has the same sorts of flaws, and is painful enough to understand that I have never actually learned it. It grew organically, so the syntax is irregular. It has most of the same small-systemisms (can I invent that word? please?) that Ruby does.

I'd be interested in hearing further thoughts about that. Do you think it's a Ruby thing, or more a matter of design and feature decisions in Rails? And if Ruby, a matter of language design and/or implementation?

David

5

Elaborate on which bit?

Prepared statements - It was always considered a truism that 85% of the time spent in a Rails App is in the database. Since Rails generates its SQL on the fly and submits it new every time, it has to repeat the work of the "prepare" every time. When I questioned this, I was told that "not all RDBMS's support prepared satements".

*snip*

With all of these benefits, the resistance to adopting prepared statements was very surprising to say the least. For the most part, the arguments against it were "MySQL doesn't do prepared statements yet, so Rails won't"

Umm.. A lot of us want prepared statements and bind variables, and I think it's even being worked on..

My personal pet peeve is how the AR validations fire off a bunch of queries, rather than just depend on db level constraints where applicable.

Does this help?

Not really. Perhaps I quoted a couple of lines more than I should have, but what picked my interest was this bit here:

> Building a transactional system is a bit (not a lot) more > difficult than I had expected, so scalable real-time systems that > pass the atomicity test require a bit of coding.

I.e. not the scalability part (which isn't ), but the transaction/atomicity issues you've been working on.

Isak

6

> > Elaborate on which bit? > > Prepared statements - It was always considered a truism that 85% of > the time spent in a Rails App is in the database. Since Rails > generates its SQL on the fly and submits it new every time, it has to > repeat the work of the "prepare" every time. When I questioned this, > I was told that "not all RDBMS's support prepared satements".

*snip*

> With all of these benefits, the resistance to adopting prepared > statements was very surprising to say the least. For the most part, > the arguments against it were "MySQL doesn't do prepared statements > yet, so Rails won't"

Umm.. A lot of us want prepared statements and bind variables, and I think it's even being worked on..

My personal pet peeve is how the AR validations fire off a bunch of queries, rather than just depend on db level constraints where applicable.

> Does this help? >

Not really. Perhaps I quoted a couple of lines more than I should have, but what picked my interest was this bit here:

> > Building a transactional system is a bit (not a lot) more > > difficult than I had expected, so scalable real-time systems that > > pass the atomicity test require a bit of coding.

I.e. not the scalability part (which isn't ), but the transaction/atomicity issues you've been working on.

Hmm.. Think (...) should have been edited out.

7

johnson_d wrote:

I disagree with my colleague's comments about "pesky </tag>'s".

I'm sure you can think of a few more examples how legacy web languages are klutzy...

PHP has the same sorts of flaws, and is painful enough to understand that I have never actually learned it. It grew organically, so the syntax is irregular. It has most of the same small-systemisms (can I invent that word? please?) that Ruby does.

No. The best way to scale is permit a super-low line count. Ruby's heel is not Perl or PhP, but Java. When one language permits 10% the line count of another, and when that ratio goes _down_ as you add features, that tells you which language has large-systemisms...

8

I think its more about knowing the Rails user base, of which MySQL-ers are very dominant, and the fact that the Rails-dev has higher priority concerns, like as evidenced in the latest release, REST and Unicode (UTF-8).

Its a very sensible decision. Adopt the features that benefit all of your user base, not just the fraction of the community trying to run Rails on extremely rarified installs.

If DHH went mental over prepared statements he could satisfy maybe 1% of the Rails community who care. And in the process lose the remainder for whom UTF-8 is a deal breaker, and the mashup community that are depending on a decent REST framework to drive their concerns.

Rails moves fast, but its not that fast. That means you have to prioritise your features, by maximum value to users, and by how difficult they are to implement.

Its not actually that different to new product development, or how a start-up might prioritise its first years activities.

9

Richard Conroy wrote:

If DHH went mental over prepared statements he could satisfy maybe 1% of the Rails community who care.

A plugin that extends ActiveRecord is just about the easiest kind to write. All the tutorials show how to do the 'acts_as_*' trick. So how about...

  acts_prepared

?

10

Java does scale upwards well, and downwards poorly. I agree.

However, I can use 1/3 of the CPU on my database server with a Java front end that I can with a Rails front end, given the same transaction load. That means that on the database server I can either buy 1/3 the hardware, or support 3 times the transactions load. It is important when the hardware is more expensive than the programmers.

On the other hand, the average Rails application does not need to handle that work load. The typical Rails application is run in an environment where the programmer is expensive but the hardware is cheap.

Line count is only part of the equation - the other part is efficient use of machine resources.

Ruby can use the resources efficiently, and as Rails matures I expect that it will be tuned to be competitive with other platforms.

11

I agree. I have been monitoring this, and believe that within a year Prepared Statements will be fully supported in Rails. With MySQL's acquisition of Netfrastructure, we can expect many of the oddities of My-SQL to disappear over a couple of years and My-SQL to become a technical leader as well as a market force.

Prepared Statements should be a relatively painless migration that would be transparent to most users. Richard Conroy's note following yours illustrates a simple migration path.

12

It's been long enough that I'd have to dig it out again. I'm not trying to ignore this, it's just been long enough that I have forgotten the details.

The short form is that MySQL defines the transaction boundary to be equivalent to the statement boundary. Since the Rails user base is primarily My-SQL users, the presumption is that the statement boundary is the transaction boundary. This led to some odd effects with the version of Rails that I first worked with.

To be totally fair, I will have to try again with a current installation of Rails.

13

johnso... wrote:

Java does scale upwards well, and downwards poorly. I agree.

Miss-understanding here. A language that minimizes code lines scales _upward_ easily.

However, I can use 1/3 of the CPU on my database server with a Java front end that I can with a Rails front end, given the same transaction load. That means that on the database server I can either buy 1/3 the hardware, or support 3 times the transactions load. It is important when the hardware is more expensive than the programmers.

That is the LAMP formula. But I thought hardware was cheaper than programmers.

14

It’s an interesting phenomenon: critics poking at obvious untapped potential in Active Record with an “if only AR did this, it would be great” mindset.

Those actually using Rails tend to be more concerned with the controller and rendering mechanics. We have a saying sufficiently common to merit an acronym: JDM. It Just Doesn’t Matter. AR is good enough to get the job done and get out of our way. There are plenty of other untapped avenues to greatness (REST was mentioned earlier in the thread), so poking around with AR plumbing starts looking like a staid, thankless, unjustifiable chore.

Those who don’t know Rails find it easiest to get a handle on and therefore criticize Active Record. This is the essence of bike shedding.

If these improvements are truly your number one kickass feature, by all means pursue them. Rails has a strong track record of growth through community contribution. I’m disappointed that these common criticisms of Active Record haven’t turned into fixes and features like so many other pain points have. I assume it’s because they aren’t actually painful, they just look bad. Until you care about them more than ‘on paper’ I guarantee nothing will change.

On that tack, we need better database drivers to really do a good job with bound args and prepared statements. Both mysql and postgres bindings are woefully behind the times with their respective API. Neither supports their native binary protocol, for example. But both do enough for AR to get its job done.

The bundled mysql.rb has limped along with spotty compatibility for years now. All of one person have stood up and worked on it. The rest of us gem install mysql and get to work building web apps.

Best, jeremy

15

Have you priced a maxed out IBM 900 series application server with 90% average utilization recently? Even without the necessary software license leases, you can buy a lot of programmers for the price of the bare system lease. When you start adding software licenses ranging from $150,000 per year per CPU per title, to make the system useful and maintainable, things get much worse in a hurry.

As per an earlier note, it is rare that Rails programs have to deal with this scale of system. Most rails programmers don't have to deal with anything but commodity systems.

16

Rails simply delegates transaction handling to the database.

Sounds to me like your issues stem from using mysql with a table type that doesn't support transactions. Either switch to a proper db, or spend some time with the mysql docs and figure out how to enable transaction support.

Java does have an edge over Ruby/Rails when it comes to distributed transactions, which afaik there's no library/clean/simple way to support in RoR atm, but then again, most of us shouldn't be working against multiple db's.

HTH, Isak

17

It's an interesting phenomenon: critics poking at obvious untapped potential in Active Record with an "if only AR did this, it would be great" mindset.

Those actually using Rails tend to be more concerned with the controller and rendering mechanics. We have a saying sufficiently common to merit an acronym: JDM. It Just Doesn't Matter. AR is good enough to get the job done and get out of our way. There are plenty of other untapped avenues to greatness (REST was mentioned earlier in the thread), so poking around with AR plumbing starts looking like a staid, thankless, unjustifiable chore.

In your shop it doesn't matter. In my shop, it keeps Ruby and Rails from even getting on the radar. I agree that mucking around the AR plumbing is a thankless task, but it is one that would be worthwhile to me since my company would stand to save a bundle of money through improved time to delivery if we could afford to operate Rails apps. As it is, even free, Rails is too expensive to operate for me to be able to justify it, even if it does make it trivial to put together a top-notch web app.

If these improvements are truly your number one kickass feature, by all means pursue them. Rails has a strong track record of growth through community contribution. I'm disappointed that these common criticisms of Active Record haven't turned into fixes and features like so many other pain points have. I assume it's because they aren't actually painful, they just look bad. Until you care about them more than 'on paper' I guarantee nothing will change.

Yes, I could do the work. Eventually I might do it (unless someone else does it first) but the entire Rails community would need to be involved in establishing the standards, or it would be a mess. As I posted earlier, there are others working on this problem already, and they have been talking about their work on this list. I expect a resolution within a year. However, like others, I have to spend the bulk of my time pursuing my paid work, and right now that is Java, xslt, C#, and COBOL.

On that tack, we need better database drivers to really do a good job with bound args and prepared statements. Both mysql and postgres bindings are woefully behind the times with their respective API. Neither supports their native binary protocol, for example. But both do enough for AR to get its job done.

JRuby with JDBC drivers should take care of that! :o)

The Fire-ruby driver (for Firebird) works very well.

The bundled mysql.rb has limped along with spotty compatibility for years now. All of one person have stood up and worked on it. The rest of us `gem install mysql` and get to work building web apps.

MySQL is good for the backing store for mostly static data for a web app (wikipedia), but it does not meet the needs of core business functions (large volumes of financial records) yet. Transactional integrity is important when you are posting data that must pass audit no matter what happens to the system. People go to jail when you get so-called "partial commits". When MySQL starts pushing the Netfrastructure back end (effectively running an enhanced version of Firebird under the MySQL API), it will have a chance to play in that arena.

I bet this is already a lot more research than the original poster expected to do! :o)

18

I use Firebird at home, and the top three commercial RDBMS' at work. When MySQL is running the Netfrastructure back end (aka a revamped Firebird) I will look at it again.

Thanks.

19

This list

20

johnson_d@cox.net wrote the following on 15.02.2007 09:53 :

That is the LAMP formula. But I thought hardware was cheaper than programmers.

Have you priced a maxed out IBM 900 series application server with 90% average utilization recently?

I'm interested by the kind of workload where an IBM 900 has been actually measured to be more cost efficient that cheap Intel/AMD based pizza-boxes frontends (web/application servers) accessing a more expensive database server like: - 2 Opteron 2220 or even 4 Opteron 8220 - redudant power-supplies, - an array of good SCSI disks in one or several RAID 0+1 arrays, probably software based for more control of the performance. the whole can use a spare system without the data disks to handle hardware failure not disk related.

This is an honest question, I'm not familiar at all with the kind of performance you can get from an IBM 900, I only know the (huge) price difference.

Even if there are workloads which are sweet spots for mainframes, I'm quite sceptic with the mainframe ability to scale cost effectively for web applications: adding processing power costs a lot compared to adding just a cheap pizza box for another frontend.

Lionel