On Mon, Jan 1, 2024 at 1:57 AM MG <mg...@arscreat.com> wrote: > 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 > > > > @CompileStatic predecessor Groovy++ (which later afaik gave birth to Kotlin).
I totally agree here. In a sense Kotlin is a statically-typed Groovy. -- Dr. Vasileios Anagnostopoulos (MSc,PhD) Researcher/Developer
