Hi Vasileios,
we use our own Groovy framework to develop an in-house multi part web
application and accompanying SQL & PL/SQL generation framework, and have
been using Groovy for 10 years, including some dabbling in the
@CompileStatic predecessor Groovy++ (which later afaik gave birth to
Kotlin).
Contrary to many ppl here I love static compilation checks - in my book
there is nothing more annoying than to get an incompatible-type-RTE, and
it also makes code more readable to use explicit types & easier to
refactor automatically (e.g. through IntelliJ). And no, I do not have
time to write a test or execute a Selenium test (suite) before every
rollout during development, to catch any potential errors of that kind,
so I would much rather have the compiler catch those, thank you ver
much* :-)
Having said that, I have come to realize what I actually want to use in
Groovy 99% of the time is @TypeChecked, not @CompileStatic, and the
reason for this is simple: Dynamic call site selection. Dynamic call
site selection is a feature I have already seen people request for
Kotlin, which e.g. allows one to easily add polymorphic method support
for newly introduced sub-types, without any refactoring effort (while
still keeping type safety, i.e. in fully @TypeChecked code).
On the other hand in practice there is most of the time very little to
nothing to be gained from using @CompileStatic, even in low level code,
because a) dynamic code execution is highly optimized in Groovy** so
there is no relevant speed difference, and b) in most cases even that
would not matter, since performance of business applications is mostly
bound by database and network performance.
Cheers & a Happy 2024,
mg
*@TypeChecked is not yet perfect here, it on occasion lets code slip
through, which later leads to a RTE, while sometimes complaining about
code which is actually valid (most of the time when using generics), but
it still is of great value, and one can of course always make a method
fully dynamic as a workaround in these cases (a bit counterintuitively
not by using @CompileDynamic, but @TypeChecked with TypeCheckingMode.SKIP).
**Alas that is not the case for JVM invoke dynamic, which is much slower
when generating a really large number of objects, which recently
required us to make a part of our SQL generation code less user
friendly, to make Groovy 3/4 with invoke dynamic as fast as the old
Groovy-specifc code which did not rely on invoke dynamic...
On 30/12/2023 19:17, Agile Developer wrote:
Hi,
I was a 4 years user of Grails/Groovy (last year mostly Python). With
the general trend of people moving to static languages, is there any
reason that Groovy needs to stay dynamic?
I see Python having the mypy approach, I see gradle moving to Kotlin
and FE mostly on Typescript.
I understand that the @CompileStatic is the supported method, but
having true static typing (with the Script-Like enhancements other
Languages added, would be beneficial).
Is there still a reason to keep it dynamic? What is the benefit?
--
Dr. Vasileios Anagnostopoulos (MSc,PhD)
Researcher/Developer
