Thursday, October 25, 2012

Ruby and analysis paralysis

Ruby is a wonderful language.  It also currently has a very vibrant ecosystem producing some amazingly cool things -- Rails, Sinatra, Chef, Homebrew, and EventMachine (my favorite) to name a few.
It also has several implementations -- MRI, YARV, Jruby, Rubinius, Maglev, MacRuby, etc.  But here a problem lies... there are just too many freaking choices.
Compounded with the active waxing and waning of open source ruby libraries ("there's another gem for that") the situation makes me quite unhappy at times.

Enter JRuby...

I first discovered JRuby when I encountered a problem with using MRI along with Powershell.
My first reaction with it was how slow it was to boot up -- this is mostly because of the Java VM.  But it fixed my problem so I was happy with it.
Later I discovered how some of my scripts which employ threading become quite performant because JRuby has real threading -- that put a smile into my face.
The thing that finally sold JRuby to me was when I had to write a Rails app that interacts with Windows SQL Server.  To be able to connect to SQL Server from Linux is quite a pain. You have to fiddle with TDS and UnixODBC.  That took A LOT of time to really get working.  Maybe it is because I am dumb but still...  So aside from the Rails app, I also had to configure ODBC in my Linux box -- that's one more dependency that could go wrong.  Later I discovered there is a library that doesn't need me to setup anything, but it has a regression bug when compiled with a lower version of the FreeTDS library.  The author decided he won't fix it because "we should be on TDS 0.9x anyways".  That is okay except when your distro ships with an older version -- because then depending on your Linux knowledge you could be screwed for a while trying to install a library (and its associated tools) manually instead of fetching from the distro's repo.
Opting to use JRuby instead, I got my Rails app talking to SQL Server in no time -- well there is that Rails boot overhead along with JRuby's.  I can also run the same app in my Windows box or in any other Linux distro without doing any further setup.

So if you are new to Ruby, or is also frustrated with the number of choices, I encourage you to try JRuby out.
To name a few benefits:

  • Consistency in experience
    • I have never had to do anything special moving apps between operating systems
  • 64-bit support 
    • by just installing the 64-bit Java runtime
  • Interoperability with Java
    • I have only tried this out a little but I found it quite cool
    • call Java code
    • make Java code call Ruby code
    • call other code that compile to Java? (Jython, Clojure, Groovy, Scala, etc)
  • Performance
    • if you use (properly) threads in your scripts you will a significant boost from the Java VM's  real threading.
Caveats:
  • It may lag in feature set and bug fixes from the main Ruby implementation
    • I have experienced this.  In my case I found a discrepancy between JRuby and MRI in the IO.popen3 call.  Sucks when I use JRuby as a wrapper for external apps at times.
  • Java VM overhead
    • boot/loading time
    • memory requirements
I hope more people use JRuby.  That way when they write those cool libraries they have been thinking I am assured I can try them out :)


No comments: