Groovy is a dynamic language - one with a very nice style and syntax in my opinion - and one of the things it has that some of the other languages it tends to compete* with like Python and Ruby is that it is based on the JVM. Because of this it always had the super easy interoperability with Java as a selling point. Additionally, even beyond newer languages like Kotlin, early on with Groovy you could always theoretically add some types, a bunch of semicolons, and verbosify a few things and viola - rename your .groovy file to a .java file get all the benefits that come with pure java.
Compilers doing more has some real benefits. I believe one under-stated advantage of Groovy and Grails is the way it gives a best-of-both-worlds approach. Grails itself takes advantage of compile time metaprogamming extensively under the hood. This gives it very good performance characteristics while keeping a lot of the convention over configuration magic that is so appealing to developers. The Groovy application code within Grails though also has access to this.
I will just link to some of the project documentation on this:
pros and cons of static compiliation:
| characteristic | static | dynamic |
|---|---|---|
| performance | improved | hindered |
| writing | harder | easier |
| adaptability | less | more |
| readability | mixed | mixed |
| test-requirement | reduced | heavy |
My workflow for actually using @CompileStatic
- Write the groovy code in a mostly pseudo code fashion
- As the method or class solidifies, add types.
- Add the @CompileStatic annotation and see what the compiler complains about.
- Fix if possible.
- Consider @GrailsCompileStatic if there are parts that just won’t be able to made fully static
{*} Do languages really compete for developers? Java 15 article - “…keep existing Java developers happy while steering potential Java developers away from newer languages like Rust and Kotlin.” It is weird to me that some people think about this being a zero sum competitive thing. Programming languages are just tools. Do hammers compete with crowbars? Sledge hammers with finishing hammers? Making a language a more versatile tool certainly has some appeal - sure, put a claw on the other side of the hammer - enhance the language and enable devs to reach for functionality within the same familiar environment or syntax, but having that be motivated by keeping others away from other language is off putting to me.