We use groovy at my company too - but not for application development, but as an embedded scripting environment that allows the user to extend the application at runtime. It does a very good job at that.
If you remove all the meta-programming from Groovy and restrict yourself to the @CompileStatic subset, Groovy is a fairly decent language. My pet peeve with Groovy is that the language itself is far larger than the "safe" subset. I imagine it would be difficult to enforce the usage of this subset across the entire project and across all developers. Also, people are tempted to bring in external libraries, and those might make use of language features which do not conform to @CompileStatic. Basically, @CompileStatic divides the groovy world in two halves; and the 50% that does not use @CompileStatic I'd rather not deal with, at all, ever.
I've seen groovy both at its best (scripting with @CompileStatic) and at its worst (ever seen the mess that is gradle?). From all JVM aliens, I would personally rank Groovy second (behind Kotlin) for general purpose use, but ranked first for runtime scripting.
Hi Martin, could you elaborate on the "the language itself is far larger than the safe subset" and "remove all the meta-programming from Groovy" ? I don't quite get what you mean: Do you write your own AST transformations in Groovy in your project, or do you mean the built in AST transformations that come with the language (e.g. @Immutable) ?
In what areas is Kotlin better than Groovy in your opinion (apart from always being @CompileStatic ;-) ) ?
I have not used much Gradle myself, so I cannot really comment on it, I only know it is in widespread use. But so is make, of course ;-)
You might have noticed that our technology stack (which I as lead picked) is very @CompileStatic (Vaadin/Ebean), and does not e.g. use Grails or GORM. Having said that, I started using Groovy when @CompileStatic did not exist (and someone had just released a static Groovy compiler (groovypp), and approach that was rejected by the rest of the Groovy devs in favor of the more flexible @CompileStatic approach, which led to same guy later designing Kotlin), but due to the excellent IntelliJ* Intellisense support for Groovy I never really missed static compilation (probably a different story if you use Groovy as an embedded scripting language without Intellisense support, though).
(Only in the last 2 years have I started to shift larger portions of our code to use @CompileStatic , since IntelliJ sometimes makes refactoring errors on dynamic Groovy code. Also static compilation is helpful for less experienced developers and/or in areas where there is no time to have 100% test coverage.)
*Ironically the company behind IntelliJ, Jetbrains, of course also makes Kotlin. Alas it looks like the conflict of interests has started to show recently, when Groovy features were only supported in IntelliJ a year after they had been introduced. Besides Java, Groovy as the #2 JVM language is the main competitor of Kotlin. I would rather see the two sides join forces tbh, but that's not likely to happen...
Kotlin enforces its type system everywhere. Every kotlin library out there adheres to it. The same cannot be said about Groovys @CompileStatic. Things like the JSON Slurper simply won't work under static compilation. Basically all the metaprogramming features contradict @CompileStatic.
I know, there are valid use cases for metaprogramming. But for general application development, I'd rather forfeit metaprogramming and get meaningful compilation results. In a way, it's nice that Groovy offers the choice, but it backfires when you need to include libraries which made a different choice than you did for your code. I don't want to deep-dive into a feature comparison of Kotlin vs. Groovy, but this fact alone (at least for me) would justify choosing Kotlin over Groovy for general application development. If you want an example of the extensive problems an optional type system can cause, you don't have to look any further than the current JavaScript/TypeScript mess. It's metaprogramming (JavaScript with monkeypatching) vs. well-defined strict type system (TypeScript) all over again. I'd rather stick to a language which doesn't even ask that question.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We use groovy at my company too - but not for application development, but as an embedded scripting environment that allows the user to extend the application at runtime. It does a very good job at that.
If you remove all the meta-programming from Groovy and restrict yourself to the @CompileStatic subset, Groovy is a fairly decent language. My pet peeve with Groovy is that the language itself is far larger than the "safe" subset. I imagine it would be difficult to enforce the usage of this subset across the entire project and across all developers. Also, people are tempted to bring in external libraries, and those might make use of language features which do not conform to @CompileStatic. Basically, @CompileStatic divides the groovy world in two halves; and the 50% that does not use @CompileStatic I'd rather not deal with, at all, ever.
I've seen groovy both at its best (scripting with @CompileStatic) and at its worst (ever seen the mess that is gradle?). From all JVM aliens, I would personally rank Groovy second (behind Kotlin) for general purpose use, but ranked first for runtime scripting.
Hi Martin, could you elaborate on the "the language itself is far larger than the safe subset" and "remove all the meta-programming from Groovy" ? I don't quite get what you mean: Do you write your own AST transformations in Groovy in your project, or do you mean the built in AST transformations that come with the language (e.g. @Immutable) ?
In what areas is Kotlin better than Groovy in your opinion (apart from always being @CompileStatic ;-) ) ?
I have not used much Gradle myself, so I cannot really comment on it, I only know it is in widespread use. But so is make, of course ;-)
You might have noticed that our technology stack (which I as lead picked) is very @CompileStatic (Vaadin/Ebean), and does not e.g. use Grails or GORM. Having said that, I started using Groovy when @CompileStatic did not exist (and someone had just released a static Groovy compiler (groovypp), and approach that was rejected by the rest of the Groovy devs in favor of the more flexible @CompileStatic approach, which led to same guy later designing Kotlin), but due to the excellent IntelliJ* Intellisense support for Groovy I never really missed static compilation (probably a different story if you use Groovy as an embedded scripting language without Intellisense support, though).
(Only in the last 2 years have I started to shift larger portions of our code to use @CompileStatic , since IntelliJ sometimes makes refactoring errors on dynamic Groovy code. Also static compilation is helpful for less experienced developers and/or in areas where there is no time to have 100% test coverage.)
*Ironically the company behind IntelliJ, Jetbrains, of course also makes Kotlin. Alas it looks like the conflict of interests has started to show recently, when Groovy features were only supported in IntelliJ a year after they had been introduced. Besides Java, Groovy as the #2 JVM language is the main competitor of Kotlin. I would rather see the two sides join forces tbh, but that's not likely to happen...
Sorry for the delayed answer - busy times.
Kotlin enforces its type system everywhere. Every kotlin library out there adheres to it. The same cannot be said about Groovys @CompileStatic. Things like the JSON Slurper simply won't work under static compilation. Basically all the metaprogramming features contradict @CompileStatic.
I know, there are valid use cases for metaprogramming. But for general application development, I'd rather forfeit metaprogramming and get meaningful compilation results. In a way, it's nice that Groovy offers the choice, but it backfires when you need to include libraries which made a different choice than you did for your code. I don't want to deep-dive into a feature comparison of Kotlin vs. Groovy, but this fact alone (at least for me) would justify choosing Kotlin over Groovy for general application development. If you want an example of the extensive problems an optional type system can cause, you don't have to look any further than the current JavaScript/TypeScript mess. It's metaprogramming (JavaScript with monkeypatching) vs. well-defined strict type system (TypeScript) all over again. I'd rather stick to a language which doesn't even ask that question.