What’s new in Groovy 2.0?
infoq.com
infoq.com
The static compilation and type checking features are quite stunning, and if they really work as advertised will truly put to rest the last remnants of my interest in Scala.
I would love to see some more direct support for doing a pure functional style of programming, but what is there is close enough and so much easier to grok than Scala, to be honest.
The macros and concurrency features are quite stunning, and if they really work as advertised will truly put to rest the last remnants of my interest in Groovy.
I would love to see some more direct support for doing a pure functional style of programming, but what is there is close enough and so much easier to grok than Haskell, to be honest.
However a big point of difference is that Groovy's syntax, being 90% compatible with Java, is orders of magnitude more accessible than Clojure to the vast majority of developers.
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.
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.
Or the "Groovy specification" which is almost completely empty? http://groovy.codehaus.org/jsr/spec/
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.
"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.
As a long time java user, i was very reluctant to learn groovy and it took grails for me to really tune into groovy. Now it's really hard for me to go back to java. :)
I also personally feel that static compilation is more of a marketing sop to the hard-core java crowd to help move them over to the dark side but what the hey, if it works, it's good for groovy.
I've got a vested interest in seeing continual uptake of Groovy, but am wondering what's holding back adoption from those of you who do Java work but haven't integrated Groovy in to your toolset.
I'm sort of half in love with the idea, half in horror - I can pick and choose which parts of my code I want to be static and which parts dynamic - is it the best of all worlds or a dogs breakfast of incomprehensible and conflicting paradigms? I don't know, but I think it's one of the first popular and well established languages to offer this so I consider it really intriguing to see how it plays out.
The JRuby guys got quite an improvement out of using invokedynamic, IIRC, so hopefully this bodes well for the future of Groovy. As others have said, Groovy is quite remarkable. To date, it remains my favorite JVM language (not to take anything away from Clojure, Scala, JRuby, Fantom, Nice, Beanshell, Jython, Kotlin, Fortress, Joy, Ceylon, etc).
[1]: Fogbeam Labs, the up-and-coming Open Source collaboration/knowledge-management company. http://www.fogbeam.com Go there now and sign up for our newsletter. It's not necessary for you to spend the rest of your day thinking about how cool Fogbeam Labs are, and how much you want to email all your friends and tell them about us too. But if you can remember a time when you were really excited about a company like Fogbeam Labs, then think back to those feelings and how that made you feel, and do the right thing.
Definitely. I'm very much looking forward to Groovy 2 support in Grails. We're just about to migrate our project to the Grails 2.x series, to start getting ready for the new hotness.
- a static type checker to let the compiler tell you about the correctness of your code,
- static compilation for the performance of the critical parts of your application,
- modularity, splitting the Groovy JAR into smaller feature-oriented JARs and letting you create your own extension modules,
- JDK 7 Project Coin syntax enhancements, so that Groovy is still as friendly as possible with its Java cousin,
- and JDK 7 Invoke Dynamic integration to benefit from the support of the JVM for dynamic languages.
Remember COBOL dominated the US for many years due to it's simplicity. PowerBuilder beat a more comprehensive competitor (SQL Windows) due to it's simplicity. It seems likely that functional languages may find a niche where they fit well (e.g. business rules) but languages like Groovy seem most likely to achieve wide adoption. IMHO of course!
Groovy is trying to play catch-up with Java currently (typing-wise) and I don't see how they will implement a modern type system in the next decade with the amount of cruft they have accumulated since Groovy's inception.
Additionally, Java 8 will ship with closures, so I'm not seeing where a niche for Groovy will remain.
I think the problem is that writing in a functional way almost requires a purist approach, so the only way in is to completely buy into the "dogma" of it. That makes adoption hard to impossible.
Groovy is almost completely the opposite - every practical whim is catered for, almost to a fault - there's all kinds of crazy stuff shoved into it. But boy is it easy to adopt. It's a quite stunning achievement how much is in Groovy and yet still - it remains almost source compatible with Java.
Wont people talk about Invoke-dynamic? how did it work out in the end?