
Recently one of our consultants, Nilanjan Raychaudhuri, asked the question “Where is groovy love?” on our internal wiki. He noted that there is a lot of interest in Ruby among developers inside Pillar but not so in Groovy. He was curious as to why there was more interest in Ruby than Groovy: community, language features, cool factor?
Here are some of the opinions from the brain trust at Pillar (edited for clarity, content, and length):
Zachary Spencer:
The groovy I’ve done has always been painful. Ruby on the other hand, provides instant delight. The analogy I use when discussing Groovy is: I go to the ice cream store and get the green ice cream, thinking it’s mint. I take a good hard lick only to find out it’s pistachio. It’s not that it’s bad (I *like* pistachio) it’s just that I thought it was mint, and I wanted mint, and I expected mint and got… Pistachio.
Jeremy Anderson:
For me I think it comes down to the testing tools. Using mocks in Groovy just seems awkward.
Shih-gian Lee:
For me, it comes down to language construct. Ruby is more concise and terse. When I use Groovy, the language reminds me of Ruby in many ways but doesn’t work like Ruby.
In the Ruby community there is a lot of innovation. Groovy is a new language and so is its framework, Grails. So far, I have not seen any great innovation came out of Groovy community.
Ruby is simple to learn, especially if you have coded in JavaScript before. I believe if someone can understand a complex language like Java, he will be able to pick up Ruby pretty quickly.
Another reason I am in favor of Ruby over Groovy is because there are many good gems out there that can boost productivity and they are not yet available in Groovy world.
I am still doubtful how successful a Groovy/Grails project can be if we work with a development team that is very conservative. Most of the people I have talked to told me that they sold JRuby on Speed and Productivity.
Clients who don’t have a good handle at good practices, such as TDD and Planning are not ready to tap into the power of a modern language like Ruby and framework like Rails. Rails really embraces agile approach.
Kevin Baribeau:
My main reason for looking at ruby has always been the community, which includes some exceptionally bright people. The craftsmanship community especially seems to be mostly involved in ruby. You can count the rails community on top of that, and the loads of other cool ideas that seem to come from that crowd.
I’m not aware of any new ideas coming from the groovy community. If there are cooler things going on in groovy/grails land though I would love to hear about them.
BJ Allmon:
Groovy and Grails seems to be going really smooth at my job and I can only speak for my experience with it.. I love it. Grails seemed like a great start to migrate legacy Java.
Nilanjan Raychaudhuri:
Grails still going to be my number one choice.
Groovy gives confidence to the client architect who worries about his less skilled developers. Groovy is something they can easily understand.
Groovy probably has the best integration with Java than anything other JVM languages. I can take a EJB and drop it to grails with one line configuration change. Java stack is typically Hibernate, Spring, some web template engine etc. In one words that is Grails. Underneath it uses the same set of frameworks that you would choose anyway if you do it in Java. It helps to get hardcore Java shops excited about Groovy & Grails.
Ruby, though, does have awesome collection of gems and using JRuby for Java is a good idea.
Justin Searls:
While Groovy & Ruby both feel about as expressive as one another, Ruby (particularly 1.9) seems much more feature-rich, pound-for-pound.
Most importantly, the smartest people I know (and know of) are prominent members of the Ruby community. I, for one, care more about being around smart people than I do about characteristics of programming languages, and Ruby absolutely blows Groovy out of the water in this respect.
This is all without even exploring the fact that the Ruby community consistently puts out some of the most novel and influential open source libraries/tools/frameworks that are merely weakly imitated in other environments.
Groovy was created in part because python/ruby didn’t run on the JVM. Now that Ruby runs on the JVM without issue, I have a sense that the inhibitions of organizations to adopt Ruby are mostly cultural, not technical.
Kevin Smith:
Groovy is a great language for anyone or any shop with a Java background that wants to transfer that knowledge smoothly. Some will consider this a negative but you can copy and paste java code into a groovy file and 98% of it will execute. This is extremely helpful for migrating corporate developers into the dynamic nature of groovy and the grails framework.
Groovy for testing is awesome… you don’t need any mocking libraries as you can take any map of functions and turn it into an implementation of any class or interface — if that isn’t enough one line of Class.metaClass.xyz = {} has been enough to solve just about anything I’ve come across.
Groovy is type optional instead of pure duck-typing. Maybe it is just me but I love being able to specify a type when I absolutely know it, but not have to all the time.
Eric Wilson:
I think the answer is pretty simple. Groovy is a compromise. We use it not because it is our first choice, but because it is something cooler than Java that a client would consider.
Groovy is not unpleasant to use, but it is unlikely to be the favorite language of many. While I haven’t found any reason not to like Groovy, I also haven’t found anything that is particularly distinct about Groovy among the modern choices. Except, of course, that valid Java is (almost) always valid Groovy.
When a language’s “killer feature” is that you can transition Java developers to it without too much trouble, it isn’t likely to generate a lot of love.
Biju Rajan:
In a java shop, it would be easier for the developers to transition to the groovy/grails path. It takes more rampup time for going the ruby/rails path.
I like Ruby as a language though I still have reservations on Rails as a framework.
I haven’t had a chance yet to work on a full scale Groovy/Grails project but I am sure it would be a lot more fun than a standard java app.
Clients may be looking for help at the Practices level (TDD, Energized Work, Planning Game, …) when they come to us, but I think that opening minds to the power of today’s languages is a fruit of efforts at the Values and Principles level – trust the team to make the right choice.