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)


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.


Bryant said...

I *think* you mean that Grails uses Spring and Hibernate, not Swing and Hibernate :)

Steven Devijver said...

Great overview.

One note though: JRuby support in NetBeans IDE is much better than Groovy, for now.

Travis Jensen said...

Ugh, somehow I always manage to fat-finger "Spring" as "Swing", probably because I used Swing so much when I first started using Java. Thanks for pointing it out.

Sammy Larbi said...

I really like the overview you gave here, but I have a couple of comments where I don't agree:

1) Regarding the IDEs, You mentioned "JRuby: There is an IntelliJ plug-in for JRuby, but it was pretty weak. The Eclipse plug-in seemed to be better."

Has the Ruby Eclipse plug-in come that far since I last used it? I ended up ditching Eclipse and buying IDEA for that Ruby plugin (and the Java development rocks too, but I was content to stay with Eclipse for that at the time)

2) In discussing the learning curve, you said "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..."

What caused you to come to that conclusion? I can certainly see it, but only if you continue to program Java but in Groovy instead. If that's the case, why take the performance hit just to write the same (type of) code? (You could just as easily "not learn" the other languages and program Java in their syntax.)

I guess you could, over time, become more accustomed to really programming Groovy, but I don't see why that would come before it does for either Ruby or Python.

Given your outline of needs, I probably would have come to the same conclusion, but the two issues I talked about above would not have tipped me in favor of Groovy.

Sammy Larbi said...

I should also mention the support for IntelliJ's Ruby plugin is incredible. I posted a question on an unrelated mailing list that (I guess) one of the developers monitored, and he contacted me, and worked with me trying to resolve the issue I was having. They released a patch within the week.

I don't know if they're always that quick, but it was pretty sweet for me.

Clinton Begin said...

I would LOVE to see some performance comparisons between JRuby and Groovy and JRuby on Rails and Grails. I'm not looking for a winner by a hair... I would like to see if there's a SERIOUS real-world performance difference, both at the language level and the primary web stack level. Mostly for curiosity sake, though. I still think they're both great. I might do it myself, but I barely have time to post comments let alone this... Anyone have some spare hobby cycles?

Travis Jensen said...

I would love to see numbers, too. I purposefully left off performance because that was too nebulous to deal with.

Just for fun, I did one micro-benchmark that read a file with a million lines, each line was a random number between one and one-hundred-thousand. Here were the results:

>> java sumlines
Time per run: 0.4526 seconds

>> python sumlines.py
Time per run: 0.7755 seconds

>> ruby sumlines.rb
Time per run: 0.8691 seconds

>> jruby ~/scripts/sumlines.rb
Time per run: 1.4584 seconds

>> groovy ~/scripts/sumlines.groovy
Time per run: 1.8696 seconds

>> jython sumlines.py
Time per run: 2.2070 seconds

Again, these numbers are less than meaningless, in my opinion, but it was fun to see the difference in how the scripts were created.

Travis Jensen said...

Regarding the Eclipse versus IDEA JRuby environment comments above, I now must hang my head in shame. One of the problems with these kinds of evaluations is you start seeing so many different "things" that they start to blur.

Sammy is right, the IDEA plug-in is the superior one. I'm updating the blog entry to reflect that.

Travis Jensen said...

Sammy, I posted a response to your second question about the learning curve aspect here. Hopefully that clarifies it a bit.

suhail said...

very good article. i too would come to the same conclusion. i think groovy has a very short learning curve for java developers. the only major difference between java(lanuguage) and groovy is that java is static while groovy is dynamic. Groovy is the DJ(Dynamic Java).

AkitaOnRails said...

I really don't see the point in such subjective comparisons.

First of all, NetBeans as stellar support for JRuby. Although both Groovy and Ruby has good enough support in tools like Eclipse.

Don't forget that Groovy, as a stand-alone language, is very very immature yet. Of course, it could leverage on years of expertise thanks to other dynamic languages, such as Python and Ruby (!)

As Ola Bini already stated: if you're going to use Groovy the same way you use Java, there is absolutely no gain. Just a performance hit. You necessarily have to make the context switch to go from imperative programming to real dynamic programming. One could argue that the farther from the source language, the better so you don't get confused. Both Jython and JRuby fits the bill. You either understand why you have closures and metaprogramming or Groovy will be useless.

Don't get me wrong, I think Groovy is a nice trial. But I think it will fail miserably as far as people keep marketing it as "the same as Java", because the next obvious inquire is "if it is like Java, why have it in the first place?"

ff said...

travis: check the benchmark i did. IMHO reading a file is not a correct benchmark because all platforms uses optimized IO operations. Real deal is manipulating the data, sorting, filtering, making calculations etc.


Bediako George said...

Hello Travis,

Very good article. Tell me, is there a reason you didn't consider JavaScript via Rhino?

Paul said...

Hi Travis,

Good review. I've heard good things about Groovy too. A couple of points:

Productivity: I'm surprised that this wasn't one of you review criteria. Especially since you stated it as one of your reasons for moving to a DL. As I understand it Grails requires you to stop and start the server Java style to effect changes. During the programming day this can add up to a lot of time!

Doing things differently: Part of the advantage of a DL is that it does things different from Java. A good example is using closures when iterating over collections. This approach rights off the whole of the Java collections API. Another example is using Metaprogramming to deliver DSLs.

My concern with Groovy is that if it looks like Java people will use it like Java. I've seen the same happen with C to C++ to Java. There is plenty of procedural C style Java out there, whilst the folks that made the clean break and went with Smalltalk are now world renowned OO gurus writing books and the like (Martin Fowler, Kent Beck, Ward Cunningham, etc) :)

Just my 2cts.

Travis Jensen said...

@Bediako George

Mostly because of time. We were looking at what we considered the most popular dynamic language and web framework combinations. Fairly arbitrary, really.


Grails will auto-reload Groovy scripts without restarting the Grails container.

I agree with you on the concern with people writing idiomatic Java in Groovy. The same concern holds true for each of languages (it is, after all, possible to write idiomatic Java in Ruby, but very ugly). Groovy makes it harder to break the mold because of its similarity to Java, but that is balanced by the ease of becoming productive using Groovy for existing Java programmers.

In the end, good engineers will recognize the power of the tools and take advantage of them. Bad engineers will continue to do what they've always done, regardless of the tools placed in front of them.

Paul said...

"In the end, good engineers will recognize the power of the tools and take advantage of them. Bad engineers will continue to do what they've always done, regardless of the tools placed in front of them."

I totally agree. The people are far more important than the tools. I wouldn't place the responsibility solely on your Engineers though.

You obviously understand what can be achieved, so why not show them? Hands on coaching/mentoring is a great way to lead and empower others.

Best wishes and I look forward to reading how you get on.


Clark said...

I'm surprised you didn't include Mozilla's Rhino implementation of JavaScript. I've used it for a while and find it a painless way to add scripting capabilities for people without a programming background. JS has the advantage of the HTML scripting community behind it, so there are mountains of JS-capable script developers. Rhino also provides methods for invoking Java methods directly, implementing Java interfaces and compiling to class files.

ZJ said...

So, it's been about a year... Looking back, did you make the right decision? Did you finish the project in Groovy or switch to Python/Jython?

I am at the point you were last year trying to decide between sticking with Groovy (after a 1 month pilot) or switching to some other language. I will probably use the points you chose to highlight as a starting point for analysis.

Thanks for the excellent insight.

Chai said...

As per the other commenter, it would be interesting what you think of the decision you made back then.
Would you still make the same decision now?
Now that django runs under jython 2.5?