Tuesday, February 19, 2008

Our Dynamic Language Shootout

As a fresh lead architect at a company coming late to the world of web based software, I've been given some significant challenges, which I'll be writing about over the coming months. We have some very interesting challenges as we take a 20 year old architecture and move it into the 21st century. Our solutions currently leverage a combination of C, Java, Perl, and others.

One of the things that is clear to us is the need to quickly revamp our user interfaces. There has been a LOT of discussion around about the benefits of dynamic languages and the ability to be more nimble when using them. As a result, we are making an investment in a dynamic language to help us in that regard. As we surveyed the landscape, we felt that our best options to look at were Ruby, Python, and Groovy. Scala is an interesting option, but we did not feel that we were ready for that significant of a switch.

For a variety of deployment reasons, we've decided that whatever we choose will be deployed on the JVM. As a result, this comparison is for the JVM versions of the languages, e.g. JRuby, Jython, and, of course, Groovy, which has no other deployment option. I want to also clarify that I have the most experience with Python and I really like the language. There is no doubt that the language influenced me in my evaluation, but I really tried to remain objective in spite of that.

As I did the evaluation, I tried to come up with a broad spectrum of important information. Others at my company gave feedback on the important characteristics. In the end, these are the features that we felt were most important: the interaction between Java and the selected language, the IDE support, the learning curve, existing web frameworks, and the existing community support for the JVM implementation of the language.

Java Interaction

Several factors make up this feature. The most obvious is how easy it is to call into Java. Since we have a large amount of code in Java, we need to be able to easily access it. Of course, all of the languages manage this without any problems.

The more interesting aspect of this is what happened the other way. All of the languages support compiling down to byte code, but how difficult is it to access code written in the language for Java. Also, since each of the languages are, in some way, a super-set of Java functionality, there needs to be a down-cast to the Java sub-set. What did that look like?

Groovy: Groovy was, without a doubt, the most straight-forward. Because Groovy supports applying types, overriding class methods is clean. Instantiating a Groovy class is the same as instantiating a Java class.

Jython: Jython is pretty similar to Groovy in its bi-directional support. It isn't quite as clean as the Groovy implementation as you are forced to use Docstrings to provide the additional type information that the class needs.

JRuby: Going from Java to JRuby is not trivial, even though JRuby compiles down to a class. The compiler seems to be primarily for faster JRuby-to-JRuby interaction.

Winner: Groovy

IDE Support

In the Java world, the IDE reigns supreme. As I sit here typing this blog in Emacs, I'm perfectly comfortable leaving the IDE behind. In reality, most of our Java engineers would not be. The flip-side is that, with dynamic languages, the needs of the IDE are less than they are with Java. Our organization has standardized on IntelliJ IDEA, so that colors this.

I did not spend a lot of time looking at language-specific IDEs. Since our developers are Java developers and will continue developing Java code, we'd prefer to have them be in one environment.

Groovy: IntelliJ has a really good Groovy plug-in. IntelliJ seems pretty committed to Groovy as well. Honestly, the support was good enough that I didn't look at the Eclipse support. That commercial-level support is comforting.

Jython: PyDev with its commercial extensions was pretty good, if a little buggy. As I said, though, IDEA is our chosen platform, so a switch would be disruptive.

JRuby: There is an Eclipse plug-in for JRuby, but it was pretty weak. The IntelliJ plug-in seemed to be better.

Winner: Groovy

Learning Curve

We recognize that there is going to be a disruptive effect by bringing a new language into our environment. We know that, for some amount of time, productivity will be reduced with a follow-on increase in productivity. The variables that come into play are how long does it take to come back to current levels of productivity and how much of an increase in productivity do we gain when the line flattens out at the end.

In the end, this is all supposition and subjective blather. Take it for what it is worth, and remember we are talking about Java engineers here.

Groovy: As a super-set of Java, it has a very straight-forward learning curve from Java. This is especially important around the APIs, since it uses the Java APIs directly. I honestly don't know whether the top-line productivity is as high as Python and Ruby, but I don't have any evidence that it is not. My gut feel is that the Python and Ruby libraries are optimized more towards their languages and will give a higher top-line.

Jython: Python's pseudo-code syntax is a short hop from Java. While the Java APIs can be used, they aren't going to be as efficient as the native Python libraries. The biggest hurdle is the learning curve of those libraries.

JRuby: Given its closer functional ties, the learning curve for Ruby is highest of the three. It also has the same issues around the Java and native libraries. I honestly think that, once the curve is passed, JRuby could offer the most productivity. I've been nothing but impressed by what I've read about Ruby in that regard.

Winner: Groovy

Existing Web Frameworks

To a greater or lesser degree, the entire Java web world is open to each of these languages. However, the thing that made Ruby so powerful was Rails. Similarly, compare Python alone versus Python with a mature framework like Django. Groovy followed Ruby's lead by adding Grails, based heavily on Rails. These frameworks leverage the strengths of these languages, and, in my opinion, that is a significant piece of what makes these languages great.

Groovy: Grails is based on Rails, with the "heavy lifting" underneath being done by Spring and Hibernate. I like the maturity of the underlying technologies. I think Grails is on its way, if it doesn't get usurped by the Java platform desire to make everything unbearably complicated. Given Groovy and Grails heavy Java emphasis, that is a major concern of mine.

Jython: *sigh* is all I can say here. While CPython has some great options, Jython went nowhere for two years. The main cause of this is two-fold: Jython's current version is 2.2.1, whereas CPython is 2.5 and so many frameworks require compiled C code for performance. Jython is just now coming back from that hiatus, but there aren't many options available for it. It looks like Django will be available soon, which will give it a much-needed boost, but in the meantime, it is a pretty desolate sphere that pretty much requires you to use a native Java technology.

JRuby: With its direct port of Rails, JRuby seems to come out on top here. Rails is a great package with some great options. JRuby does suffer some of the same compiled C problems as Jython, but since Rails is really the only web framework for Ruby, all focus could go towards that. Python does not have a "one and only" framework in the same way.

Winner: JRuby

JVM Community Support

We have an existing install and knowledge base built around the JVM that we are keeping. The disruption of moving to another deployment platform would be outrageous in a real business environment. As such, we focused looking at community support to the JVM support community. In the end, community support will make or break all of these languages.

Fortunately, regardless of choice, they all have some great communities. There are exciting things happening in each of the communities. Honestly, I with I had more time so I could participate more deeply in the communities.

Groovy: As the JVM is the only target for Groovy, the entire Groovy community is the JVM community. This obviously has some significant advantages for people looking to deploy on the JVM. It also seems to be picking up a lot of mind-share as the defacto "Java Scripting Language", which is helping that community.

Jython: As I mentioned above, Jython went through a dry period for a few years. That seems to have ended and a lot of exciting things are happening. First, the Jython community is doing a significant upgrade to bring Jython to the 2.5 Python specification. Second, PyPy is doing some very exciting things with Python overall, including the ability to target the JVM, LLVM, and C, and JavaScript back-ends in an optimal fashion.

JRuby: Sun made a nod to the JRuby community when it hired the core JRuby developers. There is a lot of effort being made to make JRuby a better deployment option than CRuby, and I honestly think it has some great possibilities.

Winner: Groovy (by a nose, and only because of the number of people using it)

Conclusion

I don't think it should surprise you at this point that we chose Groovy. Even being openly biases towards Python first and Ruby second (hey, it's cooler :), I could not, in good conscience, choose either of them for melding into our existing environment.

If I were starting from scratch on a project, my choice would be very different. If I wanted to target the JVM, I would choose JRuby (at least until Jython 2.5 and Django are available); if I wasn't targeting the JVM, then it would be, for my Python, but I'd be equally comfortable choosing Ruby.

Regardless, it is going to be exciting to breath some new life into some stilted development practices. I have good confidence that we will be very successful with this. In a later post, I'll discuss some of the ways we are going to be using Groovy and how we will decide on using Groovy or Java for the development of function points. I will also come back and discuss whether we get the benefit we hope out of this, but that will be some time before that can be determined.
blog comments powered by Disqus