What's the current state of Groovy? Has it seen much adoption, compared to something like Jython or JRuby? Does it have any commonly-acknowledged flaws?
I looked at it years ago, around when it first came out, and it gave me a negative impression as being sloppily done and a bit amateurish, so I went with Jython. My impression is that they cleaned up their act and saw decent adoption, but I don't know any more than that. It seems eclipsed these days in favor of Clojure and Scala.
Yeah, the adoption is pretty good, definitely compared to Jython / JRuby. Multiple conferences dedicated primarily to groovy / grails (gr8conf US coming up on Minneapolis on 30-31).
I think Grails is driving a lot of adoption, but I also see it popping up in vendor products that need a scripting language or DSL that integrates with Java easily. Neo4J and Cloudify (Gigaspaces product) come to mind as recent examples.
Yep. A lot of groovy adoption is "under the radar" precisely because it blends so seamlessly with Java. It may just be a build script or used in unit tests, but it is popping up all over the place.
Also under the radar because such companies using Groovy sometimes ask us to not speak publicly about the fact they're using Groovy... to my great disappointment!
Mind you, I'm comparing Clojure, the whole language, to Grails, which is just one framework. While it is true that most Groovy work involves Grails, there is also some Groovy work that does not, so the results of this comparison, if anything, understate the gap between Groovy and Clojure.
Virtually all Groovy work involved Grails. There's no other reason to adopt Groovy. If you need standalone scripts in an IDE, it's easier to use, say, Eclipse Xtend (http://www.infoq.com/news/2012/06/xtend-release-10)
No, Groovy is used in many other places than Grails.
One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
But actually, one of the very big use cases for Groovy outside of Grails is as an embedded DSL, for business-oriented languages, to further customize the business rules of an application, for configuring it, etc.
Groovy's used in many sectors: healthcare, insurance, banking, travel, scientific simulations, biomedical, etc.
> No, Groovy is used in many other places than Grails. One can think of the Gradle build automation tool (http://gradle.org/), for instance, which uses Groovy as a DSL.
Gradle's the only provable specific example you gave of Groovy being used as a DSL. But is Gradle used for much more than building Groovy, Grails, and Griffon?
Unfortunately, I cannot give some of the real-world DSLs that I know of or that I've worked on, as my customers request that we don't publicize that information.
Just to give you a couple examples which are more or less public, I can mention the Amadeus travel company (whose services are used by 80% of airlines and travel agencies in Europe) or the European Patent Office who did presentations at conferences about their usage of Groovy for DSLs.
The various sectors I mentioned earlier are sectors for which I know companies that are using Groovy for such DSL purposes, although I'm not in a position to publicly speak about them unfortunately :-(
As for Gradle, yes, of course, it's used beyond the Groovy ecosystem. For example, the Spring project (and other related Spring projects) is built with Gradle, as well as Hibernate. Some major projects have switched to Gradle from Maven.
Your statement is reductive. You can replace xtend by all the new jvm language. In fact these languages haven't proove anything. On the contrary of groovy.
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
All your examples are controlled by the Groovy/Grails business in some way. Groovy bundles both gpars and Swingbuilder in its distro, and Spring is bundled in Grails.
The Not-Invented-Here mentality has always been prevalent in the VMWare-funded "Gr8te" ecosystem. If someone independently builds something using Groovy or Grails, such as Alex Tkachman, Roshan Dawrani, et al building Groovy++, VMWare make excuses to reject it, then build their own version, Groovy 2's static compilation, probably copying plenty of code out of Groovy++ along the way.
This mentality results from VMWare wanting to control as much of Grails's constituent technologies as possible. The reason behind Gradle becoming the build tool for Groovy/Grails, Spring, and Hibernate was for Gradleware to pitch their control of Hibernate's build, knowing they'll be targeted for a buyout by VMWare. Rocher's probably hard-balling the Gradleware execs right now, trying to screw them for as much as possible.
For me, Groovy always have this feeling that's quite the opposite of Scala: it seems that it was a language that wasn't very thoroughly implemented and has all of these bolt-on stuff on top of it. Scala seems more solid to me because of the academic background (to think that a type system can be turing complete..), and it seems that Clojure found a place on its own.
In general terms, one of the flaws for me is that I can't quite decide what's the direction that Groovy's going. For example, the 2.0v is introducion static features, but AFAIK I never noticed any interest on static features (of course the groovy team should have much more to say on this). Other thing that I didn't like was the stack traces when an exception ocurred: due to the nature of the MOP, the stack traces were always very full of 'garbage' (this was some time ago, I don't know what's the story now). Another example is on the link: if you want to enable invokedynamic, you have to switch some flag on the compiler. If you compare to jRuby (which I know is not directly comparable but as an end user I really don't care) it's alread turned on if you are using the proper jRuby and JDK versions.
OTOH, I think Groovy nailed the Java interop spot on (flawless Java invocation/interop, integration with Ant, maven, etc) which is probably one of the good reasons to use Groovy.
If you consider SO to give a reasonable feedback on popularity, here's the nr of tagged questions:
Having this said, I still think that Grails is one of the best web frameworks for the JVM, although I would like it more if the plugins would have better maintenance by the community.
The static features in Groovy 2.0 look like they were integrated from the Groovy++ project. Seeing as how there was an entire side-project created by the community I'd say there was a big interest in adding static type checking to Groovy.
The static features were not integrated from the Groovy++ project, as it differed in various ways compared to what we had in mind for Groovy. But Groovy++'s definitely been a great inspiration for us when we developed those features, and the project clearly showed the interest of the community for that.
This is my impression, too. I think Groovy's "static" features are a reaction to a lot of developers realizing that "statically typed" doesn't necessarily mean that the language has to be as cumbersome and verbose as Java.
Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.
Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.
Meanwhile, the language gets more consistent and polished with every release.
The static features of Groovy 2.0 are actually a reaction to users demand and wishes.
You can read the article to have a more elaborate explanation of this, but in a nutshell, our users want to be able to type check their code especially when Groovy's used as a kind of "scripted Java" as they expect the same feedback as the java compiler provides. Especially when Groovy is used "à la" Java rather than to rely on its useful dynamic features. And our users are also interested about pure raw speed for computations, or avoid being subject of monkey patching, hence why static compilation matter in some situations.
I don't want to enter into polemical arguments here, as I have nothing against Scala, on the contrary. But your arguments about type systems vs dynamicity or supposed Groovy's drawbacks don't really seem to be factual and backed by any concrete claims or analysis. So I won't comment on that.
In terms of some of the organizations I know that are using it: IEEE, NetFlix uses it for many internal apps, Target, one of the largest hedge funds in NY area, LiquidNet. I think there are less publisized stories about it because it is more focused on enterprise, which naturally is less open about what they use. However, the community is great, there are a ton of plugins, and VMWare has done a good job continuing to support it as parts of SpringSource ecosystem.
It's the same way that there are so many Spring / Java apps being written out there (including in startups), but they rarely come up on HN as opposed to some of the newer kids on the block, ala node.js or rails.
Banner, the software quite a few universities use for student record management and other things, has migrated from PL/SQL to a Groovy on Grails system in their next version so that will push a bunch of people to learn Groovy.
I looked at it years ago, around when it first came out, and it gave me a negative impression as being sloppily done and a bit amateurish, so I went with Jython. My impression is that they cleaned up their act and saw decent adoption, but I don't know any more than that. It seems eclipsed these days in favor of Clojure and Scala.