Submitted articles
The Past, Present and Future of Ruby
In the Beginning
Yukihiro “Matz” Matsumoto wanted to create a programming language “that was more powerful than Perl, and more objectoriented than Python.” Ruby was conceived in early 1993. It was born in Japan 1995, when it was released in the wild to the domestic Japanese newsgroups, just before Christmas. Matz has kept the Christmas launch tradition for all major releases since, as a gift to the open source community and the world!
Adoption
Ruby’s growth and adoption accelerated at the end of the 1990s when the first English language mailing list began. By the end of 2000 the first English book “Programming Ruby” was published. But there is nothing that has sparked the adoption of Ruby than that of Ruby on Rails.
In 2004, most of those who were developing for the web, including myself, saw David Heinemeier Hansson introducing Rails and were blown away. Seeing the ease of creating web interfaces in order to perform CRUD operations was child’s play.
A tsunami of web developers started picking up “Agile Web Development with Rails” and cranking out new and exciting web applications – often setting new standards in UI design and business.
A few years passed and the terminology of CRUD faded away into a distant memory – for those in the Rails community – and everything became REST. There was a paradigm shift. No longer were the minds of Rails developers anchored to the notions of the database operations of CREATE-READUPDATE- DELETE but they were freed to think of a Rails application as a full fledged web service where resources can be created and modified via RESTful routing, not just database rows. APIs became easy to create, making it easier for consumers to enhance their experience using these new services, allowing data portability which was seldom seen on the internet. Web 2.0 was really here.
Once REST was introduced to the mainstream the other non-Ruby frameworks clambered to duplicate the simplicity. More RESTful Ruby frameworks sprouted and got to some level of maturity before non-Ruby frameworks could catch up. This was due to some technical restraints in other languages and frameworks. Rails is agile and bold enough to do the right thing, drop wrong conventions and evolve. Due to it’s agility – it can survive and flourish.
Rails, since its introduction and subsequent revisions has been leading the pack when it comes to conventions and adoption of web standards.
Ruby and its Virtual Machines
Ruby and Rails hasn’t always been easy to configure, deploy and scale. Some of the problems are the same as other platforms and languages and some are down to the default implementation of Ruby.
Ruby MRI or CRuby – 1.8.x
Matz’s Ruby Interpreter or MRI is the de facto Ruby version used by the community. It is written in C and it is primarily used because most Ruby gems (libraries of software) are compatible with version 1.8.x, since it has been the longest running stable release of Ruby whilst community has grown. It’s also shipped with Mac OS X, the platform of choice by Ruby developers.
Whilst a person could write beautiful, simple and powerful code there were some obstacles when deploying and scaling up. MRI had a few technical down falls namely, speed and the lack of native threading support.
Along came Koichi Sasada to address one of these issues.
YARV or KRI – 1.9.x
Koichi Sasada wanted Ruby to be fast. He created Yet Another Ruby VM, YARV. It’s goal of speeding up Ruby was successful and was officially used in the release of 1.9.x – and christened KRI, Koichi’s Ruby Interpreter.
With the 1.9.x release there were some syntax changes breaking a significant number of Ruby gems. This is one of the stumbling blocks for it’s adoption by the community.
YARV also shipped with green threads as well; no native threads yet!
A number of projects, most notoriously, “Ruby 1.9 or Bust” are working hard on making gems Ruby 1.9 compatible.
Ruby Enterprise Edition – REE
Is a fork of Ruby that aims to improve a Ruby application’s memory footprint through a series of garbage collection tweaks. REE with mod_rails/mod_rack (aka Passenger), is becoming the default standard when deploying Ruby applications to a VPS or a dedicated server in production. Big names like the New York Times and Twitter are using it in production with favourable results.
JRuby
CRuby, whilst usable in production in one form or another, still has it’s obstacles when it comes to the enterprise mindset.
Along came JRuby, with native threading.
This was Ruby’s backdoor into the enterprise. Many were reluctant to adopt Ruby on Rails because of its flaws of Ruby’s C implementations – now there was JRuby, running on the rock solid, tried and tested JVM. The enterprise started taking note. You could use the Java code that your company had invested in and still use it in Ruby. Coding can now be pleasurable on the JVM!
JRuby is maturing and in some benchmarks is consistently faster than MRI.
It’s 1.8.7 compatible and is working on 1.9 compatibility currently.
The Future is Ruby Coloured
If you don’t know Ruby – you should probably start getting used to wearing a pair of Ruby coloured slippers so that you can feel right at home because coming to an operating system or VM near you you will see Ruby becoming a first class citizen.
A number of implementations, including Microsoft and Apple funded projects, are being developed. People have seen what can be done with Ruby code and want to leverage the same power in developing on their platform.
Ruby doesn’t have an “official” language specification. The RubySpec project was set up in order to aide those who wanted to write a Ruby implementation. It contains a set of specs to ensure that it would be compatible with 1.8.7 and 1.9.
Microsoft are funding IronRuby, which runs on top of the Dynamic Language Runtime.
Whilst Apple are backing MacRuby, a 1.9 Ruby implementation that is built on top of Objective-C and the CoreFoundation Framework.
Both of these implementations seek to integrate Ruby into the foundations of each operating system, thus bringing the benefits associated with this low level integration, including threading, garbage collection and speed.
Sponsors
This web site, with its corresponding services, are provided because of the support of our sponsors who help in a number of vital ways. All the sponsors believe in the Open Source ethos and willingly offer their support. Please recognise this support by considering them when you require services in their field of expertise. Finally without the commitment from the community this would not be possible, so thank you to you all.
Founders
Sponsors
