Why is Ruby on Rails so darn slow?
'Weird and hard to understand'
In a keynote at the Silicon Valley Ruby Conference last week, Bray called Rails "a big deal, a hot deal". And the Sun Microsystems director of web technologies is walking it likes he talks it: he's using a lot of Ruby for his development.
"Let's face the facts: Ruby is too slow," Bray told delegates. He says Ruby 1.8.6 - which dominates the enterprise landscape - is up to 20 times slower than Java.
And, despite tests, the cause of the problem remains unclear - is it compilation of Ruby or "some pretty freaking complex and scary stuff" in Rails.
"When you start to run Rails, you get wildly non-linear performance. Rails has worked well on Ruby 1.8.6... everything else is a work in progress. It's weird and it's hard to understand," Bray said.
"Ruby is richly festooned with core libraries and APIs that aren't built in Ruby, they are built in C," he said.
Fellow keynote speaker John Lam, a Microsoft project manager who's leading work porting Ruby to the .NET Framework with IronRuby, also noted "strange anomalies" in the way Ruby works.
Various initiatives are underway to address the Ruby speed problem. These include the Smalltalk-inspired Rubinius that Sun is supporting; the somewhat obscure Maglev; and - of course - JRuby. This runs on the Java Virtual Machine and is up to five times faster than Ruby, according to Bray.
In spite of the go slow, Bray delivered a robust endorsement of Ruby on Rails. For him, the Rails framework drives Ruby's success and gives Ruby an edge over PHP and Sun's beloved Java in speed of development, scalability and maintainability. "The majority of Ruby in the world is driven by Rails," he said.
Rails offers a clean, prescribed and predictable framework that - like PHP - get some of their advantage from choosing to do less. Java Enterprise Edition, meanwhile, is designed for "infinite flexibility".
PHP is widespread and is used in massive applications such as Facebook and Wikipedia, but the accompanying PHP frameworks such as CakePHP, have not followed in terms of deployment, breeding "spaghetti code" that's difficult to fix and extend.
According to Bray, the prescriptive nature of the Rails framework suits most web front-ended applications' database batch needs when it comes to create, repeat, update and delete. The downside? If you need your database calls to do something a little different, you're on your own.
Speed of development is the number-one reason that CTOs at big banks and airlines are calling Bray in to advise on Ruby. "They've heard it gives them applications in months rather than years. That's why Ruby came out of nowhere," he said. "You can get something done faster in Ruby once you've got it built, you can do updates and maintenance faster than you can in PHP."
Other languages could learn a thing or two from Rails and Bray predicts frameworks would become more "Rails-like" - meaning the future does not belong to Ruby on Rails alone.®
Sponsored: Customer Identity and Access Management