Over the last several weeks, I’ve been asked a few times “Why Groovy?” More specifically, it’s phrased like “Why should someone who already knows PHP/Ruby/ASP bother to learn Groovy?” or “If I was starting off a new project from scratch and had a choice between XXX (Ruby, Python, .Net, etc.) why should I use Groovy?” I’ll attempt to tackle these as a whole, though there’s a bit of nuance between these questions I might get to also.
First, some background. I’ve worked with web technologies since late 1995 (December, I think). I got started in Perl, but was introduced to PHP/FI (PHP2) very quickly. I used both Perl and PHP, then later ASP, from 1996 until around 2000/2001. At that time most of the work I did focused on PHP. In the intervening years, I’ve done small utilities with Python, played around with Ruby (nothing professional), Java (mainly doing Lucene/SOLR stuff), some .Net (a desktop app and webservice) and done a bit of Flex/Flash/AIR. I’m by no means a polyglot at the level of a Neal Ford or Venkat Subramanian, but I am comfortable working my way around new languages (except Erlang – another topic for another day!)
In mid 2007 I was introduced to Groovy and Grails via presentations by Scott Davis and Jason Rudolph. The presentations really got me excited about development again. A somewhat new syntax with some nice features to make some of the boring stuff a bit easier (or redundant), some newish (to me) features (lambdas/closures) and a passionate community excited about the language were all reasons enough to get me interested in diving in to Groovy and Grails.
Looking back, this was almost the same semblance of qualities which attracted me so much to PHP back in the mid/late 90s. There were certainly enough things in the language which made all the Perl/CGI stuff irrelevant (setting headers, parsing out POST values or loading the behemoth CGI.pm, etc.), the community was small and excited about the developments (especially when PHP3 hit the scene), and it was different enough (both language-wise and context-wise) from the early VB and Notes work I’d done to get me hooked.
These are also likely the same qualities which get many people excited about Ruby. I’ve done a small amount of Ruby, and certainly appreciate the elegance of the language (in some cases) and the efficiency people find in Rails. I just haven’t quite got ‘bit by the bug’ the same way I did with Groovy and Grails. Yet. Maybe that’ll change. I’m working my way through Obie Fernandez’s “Rails Way” book these days.
But back to Groovy. Why should someone learn Groovy? I think there’s some abstract arguments to be made, and some practical ones. I don’t make any claim that these are uniquely my arguments – I’m sure they’ve been made before, just not on my blog. 
Abstract
Learning a new language is good
At CodeMash 2008, Neal Ford gave a good keynote on the value of learning multiple programming languages. When learning new programming languages, you get a better perspective on how problems are tackled by different camps, and can more easily learn to break down whatever problem you’re facing in different ways. I do think you learn to think differently because of it.
This is not much different from being able to read/write multiple human languages. My limited experiences learning Spanish and travelling to other countries has forced me to rethink how I use my words, and more importantly, how others may react to what and how I communicate.
This isn’t to say you have to be a master at every single programming language around. But getting outside of your comfort zone will force you to rethink some assumptions about how you develop in your primary language(s). You’ll also be exposed to other tools and techniques developers from other camps, which can also give you new ideas about how to tackle your day to day work.
Groovy is new, but not so new that you’re going to find breaking bugs every week like you might have a few years back. The community is open and willing to help newbies. This combination makes a great candidate for a learning language. Yet the skills you learn can have immediate applicability, because Groovy compiles down to Java.
Learning a dynamic language is good
Jared Richardson gave our JUG some advice last year – learn something different. This applies to the point above, but he was more specific. To people who’ve only done Java their entire career (or C#, for the .Net people out there), learn Ruby, or Python, or Groovy. This echoed Venkat’s point at CodeMash 2009 (lots of people are making this point these days!)
There’s productivity benefits in dynamic languages, and many of the drawbacks people have traditionally levelled against dynamic languages simply aren’t true, or aren’t true *enough* to warrant avoiding them.
Groovy is an excellent standalone dynamic language for learning dynamic language concepts. The integration it has with Java makes it that much more comfortable for Java people wanting to experiment with dynamic langauges, but with the ability to fallback to ‘mainline’ Java, even in the same file, should they feel the need.
Learning a statically typed language is good
Many of the suggestions I’ve heard have been aimed at Java/C# people, urging them to took at dynamic languages. I think there’s also something to be gained by people traditionally using dynamic languages like PHP, Python or Perl to learn from statically typed languages. Understanding why compilers need certain things spelled out for them, or at least the implications of doing so or not, is a useful thing when thinking about how to write code.
Because Groovy sits on top of Java, you can be as dynamic or as static as you want. Want to declare your property types as String, Int, Float, etc? Go ahead. Want to skip it for now? Skip it. Groovy makes a great learning environment for dynamic people looking to learn more about one of the most prevalant statically typed languages out there – Java.
Practical
Ecosystem
The Java ecosystem is one of, if not, the largest software ecosystem in the world. If you need a library for something, there’s likely a Java version of it. Because Groovy and Java can coexist in the same project (even the same file!) reusing all the solid libraries out there can be a real time saver. There’s quite a lot of industrial-strength open source stuff already out there in Java. This is not to say it’s “better” – certainly you could write the same libraries in almost any language. Given that it’s usually already written, though, the practical argument for the rapid development aspect of Groovy gluing together the functionality of strong, time-tested Java libraries is a hard one to ignore.
The Apache foundation has a sizable library of high-quality Java components for many needs (Roller and JackRabbit come to mind). This is the sort of ecosystem I’m referring to.
Compact syntax
Optional typing, closures, builders and other goodies in Groovy make some of the repetitive boilerplate Java code (which made for nightmarish maintenance) a thing of the past. I understand that other languages have this advantage too in some measure. PHP could make most Perl code shorter *and* more understandable at the same time, for example. If you like Ruby compactness and elegance, you’ll like Groovy’s too. It’s not 100% the same, but definitely a similar spirit.
Productivity
This is more a plug for Grails than Groovy. The Grails framework makes it very easy to build simple-to-moderately complex applications very quickly, and makes the very complex ones *easier* to manage. The plugin architecture has spawned a growing mini-ecosystem of its own, and there are dozens of plugins to help manage many different aspects of your projects, from UI to database to security and logging and more. The “domain first” strategy in Grails, coupled with the heavy-hitting GORM library, can also make for very rapid prototyping.
Being able to write this sort of code as a domain:
class Person { String name String email String phone Date birthday static constraints = { name(nullable:false) birthday(nullable:false) } }
and have to do *no* database work because GORM creates the database tables for you, coupled with scaffolding which will generate (beforehand or at runtime – your pick) the forms with appropriate validation (and internationalization of messages) lets me focus on sketching out ideas of data structures, flow and business logic rather than thinking about creating databases tables and relations and stuff. You *can* manage all that by hand if you want (and you might *need* to later) but for getting ideas out quickly to test them, Grails has helped me be very productive.
Newer language features
Groovy is new enough that there’s still some new language features making it in these days (multiple assignments, for example). But even if Groovy didn’t make one syntax change ever again, the syntax set is still far advanced beyond the traditional Java language. Pure Java might not get Groovy’s feature set natively for many years, but you can enjoy the time-saving features today.
Drawbacks
Are there any drawbacks to Groovy and Grails? Yep, there’s some. Stacktraces in Grails when you hit an error really stink (still). Groovy isn’t as fast as native Java (and may never be). There’s a bit of a one-time startup hit due to some compilation (which is getting shorter every version). I’m sure there’s others many of you can think of.
Should this be enough to keep you away from at least *learning* Groovy? I’d say emphatically *no*. Learn it. Play with it. Take the time to soak up the ideas that are different from what you do day to day. You’ll learn some new things, and will likely see your ‘regular’ language in a new light.
Wrapping up…
I still do PHP work, and probably will for some time, though I’m doing some Grails these days too. But the experience of having worked with Groovy and Grails the last 18 months or so has made me rethink my PHP yet again. It’s not that I wasn’t aware of other language ideas (I’d put together one of the first MVCish frameworks for PHP back in 2000) which could be implemented in PHP. However, continually keeping a pulse on other technology camps continues to make me a better developer.
The hardest thing is keeping a balance. Many people suggest learning a new language every year. I’m not quick enough to be able to do that, only because once I get in to one I like I tend to dig further in to that. But I will likely do more Ruby this year, and continue with my PHP and Groovy as well.
I hope this has given you some food for thought as to why Groovy deserves some investigation if you haven’t done so already.
Tags: advocacy
Personally I was sold on ruby 5 years ago, mostly because matz is so darn cool (even though his english is still not perfect! But his ideas are very solid…)
Anyway, my only complaint is that you tied Ruby too much together with Rails.
The big idea _behind_ ruby is about IDEAS in general. It is not only that “there should be more than one way”, the real thing for ruby is that patterns are everywhere. Beauty can be everywhere. One just has to shift attention and focus onto something differently.
How did Bruce Lee say… be like water. Formless. Shapeless.
(Yes, I _had_ to add that quote because I love it…)
PS: In my personal experience people who do heavy java stuff really do a lot of groovy AND like it a lot. But i am coming from a different angle, perl/php, lateron ruby (and nowadays actually a lot of C# due to job requirement, but ruby saves me from it getting too boring)
Hrm. I didn’t think I was tying Ruby to Rails – I only made one mention of Rails at all!
I’d like *every* Java developer to be doing Groovy, enjoying it, *and* buying subscriptions to GroovyMag, but I’m slightly biased!
To what extent is the “ruby patterns are (or can be) seen everywhere” similar to the “smalltalk did this 20 years ago” and “everything reinvents lisp” comments we read from ‘old timers’?
Responding to some offsite feedback on this post:
In some ways, there’s no good reasons to learn any language over any other, except perhaps what will pay the bills.
I likely could have given specific examples of the productivity benefits I’ve personally seen. That might have made things a bit more concrete, but really, anyone can turn around and say they’re more productive in PHP, or Rails, or whatever. Some of the things I find productive in Grails will probably be another blog post later on.
Ultimately, there was some magic combination of new features, people I’d met in the community, familiarity, and ability to be productive quickly which kept me going with Groovy (and Grails). For some people, that combination is something else.
By ‘ecosystem’ I was meaning more the software that’s available prewritten, not the community so much (though community can be important). For some tasks, there’s a huge number of PHP apps written (blog engines, cms), which gives PHP an advantage in those instances. In many other cases (message queuing, for instance), there’s more mature Java libraries that make those tasks much easier. That’s the sort of ecosystem I’m talking about. The Apache foundation has a great number of strong quality components for Java.
I would really advocate for people to learn most languages, not just Groovy. I’d also meant to write, as an example, that I’ve been in some groups (and conferences) recently where the bulk of the “enterprise” developers still had no experience with (or clue about) dynamic languages and the rapid development times they can provide. For Java people in particular, Groovy is a great ‘testing ground’ for trying out a dynamic language without giving up traditional Java safety nets “cold turkey”. For people *not* coming from Java, Groovy is still an easy download and setup experience (well, in my view it was) which can get you up and running quickly.
Here’s a Groovy file I wrote to load a Spring-based war file into groovy shell, then call real methods on fully configured spring beans: http://blogs.foognostic.net/2009/01/introducing-jawarepl/
I havent tried groovy but I have rails. I quit a job because an errant manager insisted I lead a team to implement a rails app in 2-3 weeks that could have been written in Java in a few days.
Fact is, the rails project would have failed or been a waste of time prototype that got left on the cutting room floor. It was a war of sorts the manager was trying to disenfranchise another team (a java team) by changing the game and the rules.
That probably says nothing about ruby or rails, but it is a footnote to all this escapism. If being a professional was about tinkering with things that noone will support all the way to production and then rewriting the app in the status quo language then I agree with this post.
I think eventually there will be a de facto java scripting language. I doubt it will be groovy or grails.
i’m not sure how i got here, but i’m glad i did. sometimes, we get ourselves stuck in our own little worlds and miss a lot of things. i’ve been working with cocoa since sometime in ’04 and rails since early ’06, and i’d never heard of either groovy or grails before tonite.
grails doesn’t particularly interest me as i use the real thing, but groovy looks like it might be kind of fun. and it looks like i’m in luck, i can get 1.5.7 from macports! i just turned on the textmate bundle for it, and now i’m gonna go play with my new toy¹ for a week or so! thanks!
¹ toy was not used in a pejorative sense
The post is great, except it needs some examples (a lot of tiny ones).
. The reader get the abstract opinion, but no more than abstracts ideas!
You gave drawbacks, advantages and some subjectives opinions, BUT, in such points, some examples in form of comparison between Groovy and whatever else will declare the point. It’s like the desire of creating instances with *only* interfaces without implementations
Anyway, that was a great post and I really enjoyed it. Thank you.
Really Great write up, thanks for taking the time to do this!
We started using groovy/grails about 6 months ago. Must say best thing we ever did as we have a lot of Java libraries and could with the help of grails write some real complex applications really fast. I love grails and hope now that the guys from spring has bought it , it will become even better !!!!
In general, the points you made would hold for any dynamic language on the JVM with Java integration. For example, I could do a word-replace on your post s/Groovy/JRuby/g and come up with almost the same thing. JRuby also has some nice features that Groovy can’t match because of its design philosophy, such as a super-dynamic call stack and trivially open-classes. This does come at a price though (performance), which is part of why Groovy doesn’t allow dynamic constructs of that variety.
I think that Groovy’s biggest selling point is the strength of its integration with Java. Outside of Scala, I don’t think there is any JVM language which integrates as closely. Groovy uses the JVM call stack (unlike JRuby), real JVM classes (not faux stubs), and provides joint compilation with Java sources. All this means that you can bring Groovy into a Java project without any serious infrastructure imposition or architectural repercussions. This also allows Groovy to properly exploit a number of HotSpot optimizations that aren’t possible in less integrated languages like Kawa or JRuby.
I think I agree with your compilation hit. When you put a grails app into production mode via the default “grails war” command, it compiles all your groovy code into JVM bytecode. Only in dev mode will it recompile on the fly for source changes, which is a good thing. Also, as the last commenter noted, the JVM can then further optimize the code as it runs.
I was a little skeptical at first myself, coming from a pure java background. I have personal feelings against Hibernate for example, but I’ve built 6 apps in almost as many months from small (twitopolis) to medium (patriotroom) and I really like the setup. The one real detriment is hosting (applies really to all java-based apps), but if you are mildly linux aware, there are companies like Linode that have cheap VPS solutions (I have several myself).
The underlying groovy scripting language is great as well. I’ve written scripts for JVM monitoring through JMX, as well as log file monitoring for error reporting. Both are kicked off from cron. It is also nice for doing quick testing of stuff. For example I use a simple groovy file when trying out regex stuff quite often.
I also do PHP, but not so much these days, as it still has its benefits. I plan on learning ruby as well in the near future (merb looks very appealing to me).
I like your underlying theme though, learn a new language. And don’t pay attention to the “ruby is better than X” or “groovy is better than Y” garbage.
Well said! I agree that Grails is wildly productive (esp. for greenfield apps) but I find straight-up Groovy to be productive as well. Once one sets up the classpath for a given project, it is very nice to start scripting things quickly, with onboard support for JUnit assertions etc.
I use Groovy _every_ day, usually to solve quick problems with our project-specific code (and/or legacy DB). It is a charming language.
[...] like it’s structure and syntax. If you haven’t looked at Groovy yet, here’s a good article on why you [...]