Bye bye Ruby, hello Groovy

I first time discovered Ruby back in 2006 (yes, I know, I was late to the game), and immediately fell in love with it. The dynamic nature of the language, the consistency, pure esthaetics and practicality certainly changed the way how I saw software development and programming languages.

Since that time, I made several attempts to integrate Ruby into my professional life and make it part of the toolbox. It was cool to play with Ruby in my spare time, but I wanted to use it on projects whose main development language/platform was mainly Java. Use it as scripting, glue language. Use it as toolkit language to e.g. generate test data, access databases, convert files, build projects and maybe even build a piece of Web applications (admin apps for example).

It never worked. The main problem was availability of the Ruby platform in all environments. While JVM was there by default, Ruby had to be installed and sometimes compiled for the more exotic platforms. And that can be a big deal if you have not full control over the environment – scenario which is pretty much guaranteed in enterprise environment. It is hard to argue with the sysadmin saying “You want to install that in production just to run scripts ? Why do not you use Perl or Bash or Java that are already there ?”

For a little while I thought that JRuby may be the way. After all – all you need is JVM and JRuby is just another JAR, right ? As Goethe said, grey is all theory and green is the tree of life :-). A language is as good and useful as are components and libraries available. One certainly does not want to write everything from scratch. Libraries in Ruby are Gems and Ruby provides very nice, mature and IMHO superior system for component management to Java JAR’s – because it handles different versions of same Gem very well (maybe some day there will be Gem hell after DLL hell and JAR hell 😉 ). Unfortunately, some Gems (by Murphy’s law most of the really interested ones) are for performance reasons built as thin Ruby layer around native (written in C) library. And JRuby does support that, making most of the Gems unavailable.

Even if JRuby had all the gems available, there would still be a problem that the Gem system and Jar system are different and do not quite fit together. Also, from language point of view you certainly can use Java objects in JRuby and vice versa, but doing that makes you feel slightly schizophrenic – what reality am I in? Is this a Java Java class or Ruby Java class ?

Third problem that I have encountered after coming up with some Web App in Rails is that the deployment model is very different from Java deployment model which myself and people in organizations we work with understand really well. We know how to deploy so that it scales, we know how to monitor and maintain a Java enterprise app. But not a Rails app with all those Mongrels, lighttd’s and other creatures :-). This leaves many open questions like “How do we size hardware for expected load ?” for which I do not have answers, and judging by well publicized issues with Rails apps scalability, even the best and brightest in Ruby world may not have either – or at least some people say so.

About at the same time I discovered Ruby, I also become aware of the strange Java dialect called Groovy. It sort of tried to do the same thing I hoped to use Ruby for, only from firm within Java environment. The original reason I did not want to look deeper at Groovy was that compared to straight elegance of Ruby, it looked kind of ugly. The Java skeleton was sticking out in wrong places and alltogether it just did not feel as good as Ruby.

I have to publicly admit I was wrong.

Being a Mac user, I have license for going after good looks and white shiny objects, but when it comes to programming languages, the good looks may just not be enough. The reality is the proof.

During last 12 months, we have quietly and very successfully used Groovy components and pieces on three large projects. It fitted perfectly, never running into anyof the issues above.

Through these projects, I learned to appreciate the Groovy way, my sense of aesthetics stopped to be offended by certain syntax constructs in Groovy and I even started to like them better than Ruby ones. For example, I am now convinced that Groovy categories are safer and better approach that explicitly alerts programmer about using class extension, than re-opening any class in Ruby (which is still possible in Groovy by assigning closure to member in metaclass). Imagine how confusing it can be for software maintenance when reopening and using happens far apart in the source code.

But the most important, the painful realization ” how the heck do I do the XYZ thing in this language ? If I only were coding in Java, it would be so much simpler ” is history with Groovy. Everything that I was used to use in last 12+ years in Java is still there, all the goodies of Jakarta Commons and way more.

Groovy community seems to be less opinionated, less self-righteous than Rails/Ruby community and more understanding for weird requirements and idiosyncrasies of enterprise environments. Rather than telling you “you should not want to do this” and “DHH thinks it is wrong”, you actually may get a helpful pointer to useful website or blog how to do that stupid thing in Groovy or Java or combination of both. Because you know, when one needs to accomplish something that seems to be wrong and illogical, being told that it is wrong and you should better forget about it does not really help. People who worked with real enterprise system’s integration understand, that cost of touching or changing certain systems is so prohibitive that it is out of question and doing the technically wrong thing may right (and only) option for given situation and customer.

Therefore – bye bye Ruby, Hello Groovy. Next things to embrace and embed will be Grails.

13 Responses to Bye bye Ruby, hello Groovy

  1. Rado says:

    Very very good post Miro. Well said!

  2. Couldn’t agree more. I’ve been integrating more and more groovy and grails in workplace… very simple and it works great. Our platform and deployment department does not need to change a thing, the learning curve for a java developer is literally 1 day! We can reuse all our java libraries we have been developing for the last 5 years… Beautiful. Unfortunately groovy got a bad rep when it first came out… A lot has happen since. Hope more people will find that out.

  3. Very well written post. Thanks for sharing

  4. […] in my humble opinion. But after doing my homework and reading numerous blog posts such as Bye bye Ruby, hello Groovy I decided to make the […]

  5. Simon says:

    Yea, the same looks my way now. I switched to groovy from ruby very fast – what’s more I read many times that the best virtual machine for ruby is JVM. So now I have groovy, I’ve got quite nice VM, nice set of tested and widely used libraries, nice community and so on.
    The only problem I’ve got is the starting time of the script. Too long for a simple maintenance script.

  6. cies says:

    gems and jars dont mix? what about:

    ok, its in early stages, but this will happen.

    without a fully functional jruby+rails stack groovy+grails was sort of justified in jvm setups. but now i dont think i want to limit myself to those rather small project. the whole groovy+grails ‘community’ seems to be backed mainly by one company, springsource, that sells on platform level.

    in contrast the r+r community is not mainly backed by a single company, it is carried by several companies and loads of enthusiasts. those companies are usually selling/exploiting stuff the MADE WITH r+r, not the framework itself. thereby the framework has much room to innovate and brings choice, as we’ve seen. (haml, rspec, cucumber, bundler, rack, merb, …, rails3)

    • Miro says:

      Being backed by one company can be seen as advantage from enterprise view (especially when that one company is VMWare, well known in industry). You may have a point wrt speed of innovation, but with rapid innovation often goes hand in hand with unfinished products, low quality, bugs that nobody bothers to fix and instability. May not be a problem for “enthusiasts” audience, is frowned upon by sysadmins as well as project managers.

      I really liked the beauty and consistency of Ruby, but do not believe in J-Something when the power of something is in rich libraries (gems), that may or may not be available on pure Java platform.

  7. What he said. I just did some Ruby for Cisco UCS (i put my first alpha basic rough UCSAPI on github and rubyforge) – but after reading about Groovy and wanting to leverage the VMware + UCS APIs in the same code, then I have to abandon Ruby and use Groovy. Thanks for these posts, Aaron. Nice to know there are others like me out there!

  8. Max says:

    It is very easy to mix gems, jars, and even C code in the same JRuby program. I have written wrappers for libpcap(packet sniffing library written in C), called Apache HTTP client libraries, used active record and nokogiri all in the same program and used Swing to paint the interface.

    It was dead simple, and the code that drives it all is elegant, clean, and concise Ruby 1.9.2.

    Why settle for the craptastic Groovy syntax and its verboseness?

    Groovy is for Java end-users that don’t have the background and motivation to move outside the extremely rigid Java box. It is definitely not for programmers.

    • Miro says:

      Enterprise system programmers are not programmers according to your terms, I guess. We like our extremely rigid Java box. Companies like Twitter found the hard way when moved from Ruby to Java (Scala).

      I would agree that Ruby’s syntax is nice, more elegant. Unfortunately, good looks are not everything

      • Max says:

        No, I am talking about people who know Java and nothing else. They are not programmers by any stretch of the imagination. They are Java end-users. Languages like PHP and Java exist for these severely undereducated folks. They are for companies that do not hire the best. Even though Ruby is much easier to learn than Java, you can’t be a simple end-user to master it.

        Twitter had no issues with Ruby. People like to blame Rails, but the way they developed Twitter, any framework would have choked on it. In the same request that posted a new tweet, they were also sending out messages to all followers.

        That is plain stupidity on the part of the Twitter dev team and has nothing to do with Rails. *insert random java framework* would have choked on it also. I am not surprised you confused Ruby with Rails.

        Scala runs on the JVM, but don’t suggest that Scala is Java, that is rank idiocy. I guess you could say Java(Ruby)? LOL

        The JVM is an outstanding platform, it is even better now that 7 is out, which flat-out admits that other languages are the future of Java. You are going to see other languages like Ruby, Lisp(Clojure) and Scala take off now that 7 have been released and over time the Java language is going to be less common for new projects on the JVM. Groovy might take off also, since it is tailor made for Java end-users, but the other languages will curb stomp groovy. Java(the language) is the new Fortran. Lots of legacy code to maintain, but few new projects will be written in it. Too bad Jython is lagging behind Python version by a significant margin, as a real Python on the JVM would be great also.

        The Java programming language is one of the worst, yeah it’s better then PHP and VB, but what isn’t? The JPL is extremely verbose and rigid, all the IDE’s and XML used is there to overcome all the severe limitations in the language. Generics is an unnecessary joke.*

        Did real support for anonymous functions, array and hash literals show up in Java 7? How about bringing MigLayout to replace every crappy layout manager that Swing uses(which is all of them)? No? Too bad, those sorts of things would have helped immensely.

        The Java libraries range from overly verbose EE, Swing, etc, to very solid,, although Apache Commons has the Java API beat in a lot of cases.

        * Why couldn’t java just support SomeObject obj = my_collection.get(5); without casting or the use of the poorly implemented generics? It should be trivial to guess what the result should be and properly handle it if the poor type system complains**, right? But no, the Java team had to use the most verbose way to solve this problem.

        ** Java is type-safe my patootie. Ruby is more strongly typed and has less type errors than Java.

  9. Miro says:

    Few new projects in Java ? Hmm, let’s check TIOBE:

    Java 19.25%, delta +0.58%. Ruby 1.325%, delta -0.66%. That takes open source (including some percentage of “toy projects” that nobody uses) into account.

    Should you look into enterprise software, the picture would be even more pro-Java.

    While I appreciate your zeal and passion for Ruby and Rails and even share some of your opinions (elegance of Ruby syntax and rather messy state and unnecessary verbosity of J2EE), there are areas where Ruby+Rails does not work well, never did and unlikely ever will.

    The Rails community got this reputation for patience, tolerance and understanding ( I kind of start to see why …

  10. Miro says:

    Closing comments. I have no time for discussions with Rails zealots that start to use word “idiocy” as soon as different opinion is presented.

%d bloggers like this: