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.
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.
"It seems eclipsed these days in favor of Clojure and Scala."
Your view of reality is being warped by the Hacker News bubble. Consider the results of Google Trend:
http://www.google.com/trends/?q=grails,+clojure&ctab=0&#...
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.
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?
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.
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.
- SwingBuilder
- gpars
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.
There are plenty other reasons to adopt Groovy, other than Grails
Your other statement are opinion, not fact.
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:
* scala 549
* jruby 342
* groovy 599
* clojure 120
* ruby (for comparison) 7,115
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.
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.
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.
Or the "Groovy specification" which is almost completely empty? http://groovy.codehaus.org/jsr/spec/