5 ms·

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

by mping 14y ago

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: * scala 549 * jruby 342 * groovy 599 * clojure 120 * ruby (for comparison) 7,115 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.

soc88 14y ago
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.
- glaforge 14y ago
  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.
blktiger 14y ago
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. http://code.google.com/p/groovypptest/wiki/Welcome http://code.google.com/p/groovypptest/wiki/Welcome
- glaforge 14y ago
  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.

by mping 14y ago

soc88 14y ago

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.

glaforge 14y ago
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.

blktiger 14y ago

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. http://code.google.com/p/groovypptest/wiki/Welcome http://code.google.com/p/groovypptest/wiki/Welcome

glaforge 14y ago
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.