Just my humble opinion on this, after being using Groovy for some ~7 years.
Il 30/04/20 15:05, Jochen Theodorou ha scritto:
* Almost all Java devs I've been talking about groovy in the last
couple of
months think that groovy is a purely dynamically-typed language.
Which in
fact turns them off so much, that they don't even want to take a closer
look.
We have static compilation for now... 4? years. Not sure how to get away
from that in the end.
I don't have the answer. But what I can say is that statically compiled
code is still often problematic. There are still many bugs, both in the
static type checker and in different runtime behaviour compared to
dynamic compilation. Using generics (apart from easy cases) can become
really hard in Groovy, at the point that you have to give up and remove
them. Not to talk about enums written in Groovy, which can become a
nightmare, at least statically compiled ones.
From a user point of view, the feeling is that, although existing,
static type checking has never been a priority for Groovy committers,
but rather an accessory feature.
* The development experience is subpar comparing to Java (Eclipse,
IntelliJ
and VSCode). Groovy Eclipse is slow, autocompletion is flaky
sometimes, etc
In IntelliJ it is not bad, Groovy Eclipse I am not using for such a long
time, I cannot tell anything about it. In the end it is missing manpower
I would say here
Groovy Eclipse improved *a lot* during the last years, from when Eric
Milles started to work on it. He really deserves the credit for not
having let Groovy die for all Eclipse users. But there are still some
issues that are really hard to fix, some of which are architectural ones
(for instance: it's impossible to set independent project-level Groovy
compiler versions in a workspace), some other are not trivial and would
deserve careful attention (like deeply reconsidering the weights given
to different code assist proposals, to improve user experience), some
other may sound "cosmetic" (like almost missing Javadoc/Groovydoc
support and really poor source formatting abilities), but are indeed
very important when using a language in big enterprise projects. Not to
talk about debugging: I think Groovy code is harder to debug on its own,
and Groovy Eclipse is missing many of the debugging features that are
available for Java (like expression introspection, for instance).
As I said a lot in the past, IntelliJ became more and more relevant
among Java developers, but Eclipse is still extremely popular. There
have been years in which Groovy Eclipse plugin was hardly installable,
after Pivotal abandoned it... and its quality was embarrassing in many
aspects, simply because it was very incomplete.
And now it's still in a very delicate position however: Eric is one and
alone. If he has to step back from Groovy Eclipse, for whatever reason,
Eclipse users will be left alone once again.
Additionally, although I don't know the internals, I suspect that some
deficiencies in the projects the Groovy Eclipse plugin is building upon
don't really help to make things smooth: I mean, if I understand it
correctly, there's no parser recovery support in Groovy core, and this
had to be done entirely in Groovy Eclipse and a huge problem is that
with the new parrot parser, the whole work would have to be done again
(from scratch?). Another problem is that the Eclipse JDT plugin seems to
be lacking the proper extension points to allow a plugin like Groovy
Eclipse to extend Java compilation without the need for patching.
Yes, for me good tooling is extremely important for the success of a
technology. After all, we have been told that one of the main reasons
fro which Gradle is now promoting Kotlin is exactly this: it offers
better tooling support.
For these reasons I think that Groovy is seen as a good choice for
testing and for scripting, but not for writing production code, at least
in medium-to-large projects.
As I said in the beginning, this is just my opinion based on my own
experience.
Mauro
