Do you want powerful jvm environment and exceptional java ecosystem? Do you want a java-like language (easy learning curve) but want to write less and in a more elegant way? Do you want a powerful scripting language? Do you want to work with consolidated technologies like hibernate and spring but in a more comfortable way? So why don't you choose Groovy and Grails?! I've been working with it for the last 2 years after many years as a J2EE developer and now i can't think to start a J2EE project without it!
I generally choose Grails (although the move to 3 is going to be a bit bumpy without all the plugins from the 2 field).
The primary deficiency I've found is startup time - when I move to other systems, I remember - oh yeah, projects can start up immediately, or in < 3 seconds, not 50. I know 3 is better in this regard, and I'm looking to migrate one project to it next month.
Grails never got the mindshare because it was jumping in to a full ecosystem. Rails, by comparison, was essentially the only game in town if you wanted to do Ruby - there weren't any other major competing frameworks.
The other big strike against Grails is... "it's different!". Most shops that are large enough to see big benefit from Grails and similar frameworks also tend to be rather stodgy and slow to change (perhaps with good reasons, but slow anyway). The sort of people who champion 'new' tech largely migrated away to completely other ecosystems (rails, node, etc). Grails/Groovy are 'different' in a scary way for "slow to change" shops, and "not different enough" for the folks who are always looking for "new/shiny" stuff to dig in to and promote. It was/is too "middle of the road", I think, to benefit from the advocacy often required for adoption. And in a crowded JVM-tech field, that hurts.
That said, it's still a great stack, and I still recommend it for many situations.
Groovy is much slower than Java, dynamically typed (even with optional typing), with spotty IDE support and with Thoughtworks recently dropping its support of the entire project, the future of the language is quite uncertain, even though it was picked up by Apache.
I would feel more comfortable picking Kotlin despite its newness: it has everything Groovy offers but it also fixes all the problems I listed above.
The Codehaus implementation of Groovy was only voted into Apache a week ago, and still needs to complete the infrastructure conversions which could take months, or longer if problems surface. Its project manager Guillaume Laforge has been making fraudulent claims about the consensus of the "Groovy Community" on joining [1]. He's redefining "Groovy" to be whatever's in their particular codebase, instead of a reference implementation of a spec as its creator James Strachan asserted right up to his last ever posting on the Groovy mailing list [2]. From there, Laforge is redefining the "Groovy Community" to be whoever's committed to that codebase, instead of whoever's contributed in any way to Groovy, including people who've haphazardly worked on other implementations of Groovy and those who've mainly written documentation. To further support his new narrative, he recently withdrew from the expert group and lead role on the JSR-241 [3] that defines a spec for the JVM version of the Groovy Language. I suspect the Apache mentors of Groovy such as Roman Shaposhnik, Bertrand Delacretaz, and Emmanuel Lecharny might not fully realize the fabrications they're dealing with.
Whether someone's called a Pivotal Project Manager, an Apache P.M. Committee Chair, a Codehaus despot, a JSR lead, or whatever, if their skills are managerial rather than technical then they generally end up relying on having the best title and position rather than what they actually do to make the product be the best possible.
As for being happy about something, if Groovy development is being effectively led by its technical people as well as not being dictated to by the applications using it, then I'd be optimistic for its future (the Codehaus-cum-Apache implementation of it anyway).
