groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Building Groovy
Date Wed, 20 Dec 2017 22:08:34 GMT


On 19.12.2017 09:37, C├ędric Champeau wrote:
> 2017-12-19 2:21 GMT+01:00 MG <mgbiz@arscreat.com 
> <mailto:mgbiz@arscreat.com>>:
>
>     Hmmm, I don't know if Paul has some comeback, but to me you make a
>     very convincing point...
>     In that case the best way forward to me seems to be to
>     1) Ask non-@CompileStatic Groovy users who can afford the time to
>     switch to the invoke dynamic variety of the Groovy jars and report
>     back on performance issues (tests that run much slower, etc)
>
>
> This has been the case for years now, and almost nobody uses the 
> invokedynamic version.

Speaking from my own experience: Of course, why would they - unless you 
give them a reason/motivation...

>     2) Add a clearly visible message to the Groovy distribution
>     download section, Maven/etc URL spots that Groovy 3.0 will be
>     invoke dynamic only, and again ask for people to use indy now &
>     give feedback if code seems to be unusally slow
>
>
> I disagree. 99% of our users don't even know what call site caching 
> is. They don't know what invokedynamic means,

You think that 99% of Java professionals do not know what a feature that 
has been around since Java 7 is ?
And even if that was the case: Google "java invoke dynamic" => 
https://stackoverflow.com/questions/6638735/whats-invokedynamic-and-how-do-i-use-it 
from 2011

> and they don't have to. It's an internal implementation detail. What 
> they care, on the other hand, is performance. So "is it slow? yes -> 
> report a bug". No one has to care about the implementation detail, 
> unless you're a language designer.

Or "is it slow? yes -> Groovy sucks (1st time user) / has become slow 
(returning user) -> let's use Kotlin"
In the web there are still posts that present Groovy as being slow, back 
from the time when it actually was, so it actually becoming slow is 
something which in my humble opinion one should try to avoid.
In my experience with technical minded people it is never a bad idea to 
explain why things are the way they are.
Paul seems to be of the opinion that it is just a problem of resources, 
but even then I think it would be better to have more input now, to be 
able to gauge the extent of the problem. Anyways, just my 0.1 EUR...

Cheers,
mg






Mime
View raw message