JRuby vs Groovy

Lately at my office there has been some conversation about dynamic languages, and which one we should be investigating to replace dead languages like, ColdFusion, there I said it. Luckily one of the dynamic language junkies left to go work for Netscape, now Propellar, because he was a Python fan boy. I looked a little into Python and I hear tons of people probably would use Django over Rails had it been out sooner. That being said, I am glad that is one less language we need to look into before we can come to the conclusion that all of them are better than what we currently have.

So where does that leave us? Well there is myself, the Ruby/JRuby advocate, and Brian the hardcore Enterprise Java/Groovy advocate. Fortunately Groovy does not have a web presence comparable in matruity to Rails. While Grails is making great strides, from what I hear the author is still not convinced it is production ready. Brian however made a strong case for using it as it gets closer to maturity because it has been designed from the ground up to be integrated with existing J2EE standards, like JTA and JPA.

I have stated many times in this on going discussion that I am up for using whatever language we all agree to best suit our needs, and if it is Groovy I am all for it. I just don’t think our existing ColdFusion/Java/Flex combo is the most productive stack we could be using. That being said I bought into Brian’s argument, until I read the ever opinionated DHH’s recent blog post about Sun’s Craig McClanahan Keynote at RubyConf Europe. This is the guy who worked on Struts and JSF and he is advocating Rails usage. The only thing this article reminded me of was that Sun has brought the JRuby team in house, while Groovy was not invited.

To me that seems like Java is going to work a lot harder to get JRuby up to snuf with it’s standards and have the money and manpower to make that happen. You may doubt their support for JRuby but with the quick turn around on Netbeans with Ruby support, I don’t think you can question their commitment to the language.

So as much as I like what Groovy has done for the Java community and believe that there is room on the JVM for more than two languages. I think Sun is going to put their weight behind JRuby and over time will stay ahead of Groovy with support and quality of implementation of the Java Specifications. I could be completely off in this assumption, but the evidence seems to point to my observation.

This entry was posted in development, languages and tagged , , , , , . Bookmark the permalink.

5 Responses to JRuby vs Groovy

  1. As a JRuby developer at Sun, I’d love to see us do more for the Groovy team. We’ve already sent them a nice server to performance-test on, and I’ve tried to help where I can. However…they’re also doing pretty darn well themselves. The truth is that Groovy faces more of an uphill battle than JRuby, mostly because it’s a newer language that only runs on the JVM, and as a result it’s only really possible for them to pull developers away from other Java technologies. Technically, there’s no reason Groovy can’t succeed. I would predict that Groovy’s success lies entirely with its community; if it grows and flourishes, Groovy will be successful. JRuby piggybacks on an existing community, and so it’s fairly easy for us to get a foot in the door. Ruby has a lot of buzz and name-recognition. As Groovy develops more and more of that kind of buzz and recognition, I’m sure we’ll see it expand quickly.

  2. Daniel Roop says:

    @Headius

    Thanks for the comments. I am excited about Groovy, and I have been following the JVM Languages mailing list so I know how open the communication is between the two projects. Much like the philosphy of the mailing list I think all the languages can benefit from each other, and should keep open lines of communication.

    That being said, I hope JRuby wins out in my shop because I am think on the web tier it will be a bigger benefit to us. I would have no problem if Groovy is adopted father back in the stack to help with our library development.

    Big Congrats to Groovy as I heard the 1.1 release candidate is just around the corner and I heard Grails has a release canidate in the works as well. Hopefully we will be able to do a PoC for that platform in my office as well.

  3. Maxim Porges says:

    I already told you guys earlier this week: ColdFusion’s not dead, it’s just pining for the fjords:)

  4. side10024 says:

    With Java go with JSF and technically Wicket and Tapestry 5 or go with Groovy and Grails thats where everybody is heading.

    Another way is with Python and Django. Rails is loosing steam maybe is the new smalltalk never will be on the mainstream.

    Perl = new C
    Python = new Pascal
    PHP = new Basic
    Ruby = new Smalltalk
    Scheme/CL = Lisp
    C/C++/Java/C# = new Assembly

  5. Daniel Roop says:

    @side10024

    I don’t know that I agree that everyone is heading to Groovy on Grails because the framework is not nearly mature enough to support most enterprise needs.

    Python and Django are good options, but we need something on the JVM so we can interact with our legacy products, and although Jython is picking up steam, I don’t think it is quite ready for the real time yet.

    Rails may be loosing steam, but that just means the script kiddies are moving on to other stuff, that doesn’t mean that Ruby/JRuby as a language are viable options.

    Very nice comparison if I were to choose a language based on my interest in it’s parent language, I would go with Scheme or Ruby. I don’t particularly care for C, and I definitely don’t want to write assembly.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>