Ruby is the R in Rails

Posted on June 11, 2008
Filed Under cognifide, development, ruby, scalability |

I would love to have attended RailsConf 2008 but alas you can only do so much in a day. Although this was a Rails conference, it seems that this year there was less talk about Rails and more about Ruby. This is hardly surprising really given that Rails is just a web framework. Yep, Rails is just a web framework. And just like any other web framework, its serves as a gateway from the web and into your enterprise. Now, after a year of doing Rails, you’re basically done. Coasting. Yes, there are tips and tricks you can pick up along the way but for all intense purposes you’ve got the badge. You’re done. You know Rails.

Now the more pressing problems and prickly questions around the enterprise, integration and scalability need to be addressed and this is where Ruby is amore compelling story. In fact, things in the Ruby space are really moving forward at break neck speed. It’s not surprising really, given the relatively few Ruby conferences there are each year, that Ruby gets to play out and steal some of Rail’s thunder at RailConf.

So what is going on in Ruby space that’s so interesting?

Ruby Implementations - Where integration is Key

First up there’s JRuby. This is a 100% pure Java implementation of the Ruby programming language. And right there is JRuby’s sweet spot. The ability to seamlessly integrate with the Java platform through Ruby is a big win for some. So running Rails under JRuby and using it as a web gateway into your Java enterprise, together with the ability to leverage mature/known Java tools and the free performance hikes that accompany it has been a very appealing proposition to some. A prime example being the ThoughtWorks Mingle product. Also, having access to the abstract syntax tree which can be shared between multiple Ruby runtimes hosted within the same JVM process is pretty neat and a highly efficient way of managing memory.

MacRuby! As a Mac User I’m excited by this implementation of Ruby 1.9. With MacRuby you can write Mac OS X applications in Ruby without the performance hit typically attributed to standard Ruby and Ruby Cocoa. MacRuby is native to Mac OS X core technologies. Damned quick with all the elegance of Ruby to boot.

IronRuby, backed my Microsoft and sits on top of its Dynamic Language Runtime (check out John Lam’s talk on the DLR), is a .NET implemention of Ruby. IronRuby enables Ruby programmers seamlessly integrate with the .NET platform, in much the same way that JRuby does on the Java platform. Ruby.NET is open source .NET implementation that does not have the same pull as IronRuby.

In fact, the main draw for Ruby developers that target JRuby, MacRuby, Ruby.NET or IronRuby is integration with the Java, Mac OS X or .NET plaforms respectively.

Ruby implementations - Standards are key

Let’s park integration. Let’s focus upon Ruby developers building Ruby apps with an Ruby-oriented environment. Both Rubinius (a spec led Ruby implementation) and MRI/YARV (currently the official Ruby) are competing VMs for running Ruby applications. Everyone started with Matzs Ruby Interpreter (MRI) but now we have many more alternatives. The Yet Another Ruby VM (YARV) project has officially merged into MRI as of May 2008 to combine the best of both worlds to enhance the official Ruby implementation.

RubySpec

But unlike Smalltalk that was really killed by competing implementations, the Ruby community, through RubySpec are collaborating on standards and competing on implementation. This is good. No, hold up, this is great! This will hopefully provide more choice to the developers to select the appropriate Ruby implementation that best fits their solution requirements. Hopefully, this will hold the community together and keep everyone pulling in the same direction. So far, that appears to be the case…

..but then there was Ruby for Scale - Maglev

Maglev is a Ruby implementation built on top of Gemstone’s VM that is written in Smalltalk. Chad Fowler goes into the why and when you would choose to use this Ruby implementation other the others. But the problem is very few people have access to Maglev. It promises the world and come on guys its time to show me the money! The community has seen is a presentation. A damned fine presentation I’m told but Charles Nutter of JRuby is not convinced and other people are already dismissing outright Maglev’s claim to scale. 100 times performance improvement is a big claim. One to watch I guess.

And Finally!

Take a look at the following code snippet:

#!/usr/local/bin/ruby

require 'scalability'

# your code

Now the Twitter guys must be get this all the time. Twitter is growing in size and its architecture will mature and incorporate different technologies I’m sure that best fits their current problems. Time will time. But to say its Ruby’s fault is a little naive at best. That said, wouldn’t it be just great if only you could include scalability in Ruby applications, Java apps, .NET apps, or whatever the platform.

Now, that would be awesome. But the simple fact is you can’t include it, you have design it in. Boooooo say the crowd. Kill joy chant the business. But unfortunately, like so many things in the software industry, you have to go the long way round (read as experience) to get desired results. Because there are no short cuts (read as foolish hacks, or inexperience) on the road to scalability…only blood, sweat and tears! But there are leg ups, tools and techniques and people to assist, but that’s any story for another day…

Comments

2 Responses to “Ruby is the R in Rails”

  1. Sebastian Zarzycki on June 11th, 2008 10:37 pm

    The problem with Ruby right now is (as I see it) old “chicken or egg” dillemma. Ruby isn’t going enterprise, because enteprise has to be ensured that everything will go well. But if Ruby will not be embraced by enterprise, there is a risk that it will never evolve since there are lots of smart folks on enterprise side and their voice and input is crucial (read : solve scalability) for further evolution. I don’t want to be mean, but when I see ruby 1.9 changes, I can’t help thinking that there is someone there behind Matz, who loves php hacking and forcing him to spend time arguing whether they should use sign : or => or # for this and that. As if Ruby syntax isn’t wicked enough.

    I was amazed looking at Maglev presentation, it’s really hard to believe that it could be so fast. And it’s not just talk about how to speed up things but very essential point from where ruby/rails can ride into enteprise hands and be used safely and successfuly. I’m just not sure that I like the scattered effort to improve Ruby. I hate this in Java community, this pretty much killed Java for me and made tedious, boring and overly complicated. Now I see the very same in Ruby, but from different angle - now we have handful of language implementations. I can understand competition, but soon we will hit 10 ruby implementations - that’s insane. Why can’t those people just gather and think together? Now, when I’m going to build application, BEFORE I even go into framework/orm system pick, I will spend another n hours on choosing the very implementation. Sigh. Unity may have its own quirks, but, c’mon, ASP.NET is way easier. And it’s not because of api or framework or even language. It’s because you don’t have to spend 50% of your development time on making choices and praying to Sparta gods that those choices will turn out to be good ones. And microsoft can just focus on improving one single united environment to make it easier for developers.

    “Show me the money” pretty much nailed this. Developers have to be attracted more. Managers have to be attracted more. Maybe we should try again with this “development 10 times faster” lines and make them actually true for large apps…

  2. cleve on June 11th, 2008 11:01 pm

    I see where your coming from and agree in part. I think all the Ruby implementations that target specific integration needs are useful but you only need one of each. Ruby.NET will probably become a distraction and fold under the might of IronRuby.

    As for Rubinius and MRI/YARV, the competition will yield better results in the long run for all. One of the results being the RubySpec that will be much better with input from multiple implementation teams. I don’t put much value behind a spec that has a single implementation to its name.

    As for Maglev, that’s deliberately trying to make some waves but until I’ve touched it, I’ll reserve comment.

    As for the Microsoft No Choice, No Brainer - its appealing for a while, but that’s simply not a place I’d like live, only visit! I like options.

Leave a Reply