Re: Feedback requested for Groovy 6

On 4/2/26 11:08, Remi Forax wrote:
[...]
>> https://groovy.apache.org/blog/groovy-async-await
>>
>> Inspired by similar constructs in JavaScript, C#, Kotlin, and Swift,
>> the proposal lets you write asynchronous code in a sequential,
>> readable style. This allows developers to leverage virtual threads on
>> our compute environments, which have ever increasing processing power,
>> but without the complexity of writing ad-hoc multi-threaded code.
>> (This is quite mature and ready for merging but hasn't seen widespread
>> testing outside a few folks in the development team)
> 
> Hello Paul,
> I think you reach peak complexity (as Brian Goetz would say) with this feature.
> 
> There are 3 problems with CompletableFeature,
> the code is not very readable and forgetting about exceptional case is too easy, you have no stacktrace so when an error occurs, you are lost, you can not profile it (because there is no stacktrace) so if your code is slow, you are lost.
> 
> Groovy is not only about the syntax, in my opinion, it's also about the runtime experience, the fast feedback, you hit a runtime error, you fix it, you continue.
> 
> This proposal does not groove me, it's syntactic sugar on top of a "Future Closure".

I agree. In the beginning I was quite interested, but the more I think 
about it, the more I think this is not the right direction. I mean, yes, 
we cover the exceptional case, so there would be some benefit, but I do 
not feel it is enough.

> There is a need for async being easy in Groovy, but not based on a design similar to completable future.

I agree

> Early erlang / early Go design, with a transparent management of the exception / cancellation / timeout would be far better.
> 
> Something like, an async keyword to create an asynchronous expression and a await + all/any and timemout should be enough
> 
> def captureTheFlag(hero, villain, flag) {
>    var heroGrab    = async hero.grab(flag)        // a Task object with a volatile state typed State := NON_STARTED | Success(V value) | Failure(Throwable t)
>                                                   // + an owner thread, so it can not be submitted/awaited by more than one thread
>    var villainGrab = async villain.grab(flag)
> 
>    var winner = await 1s any(heroGrab, villainGrab) else "no winner"     // run using virtual threads or not (an Executor)
>    
>    print $heroGrab() // either the value or throw the exception thrown by hero.grab() (or a runtime exception for NON_STARTED)
> }
> 
> The method captureTheFlag does not need to be flagged as "async", there is no wrappring/rewriting to a completable future code
> 
> 
> I think you should reconsider how to make async easy in Groovy, both in terms of syntax but also in terms of what's happen at runtime.
[...]
I am aware that this is more aligned with the Go/Erlang design, but a 
couple of questions:
I) I assume something like async{hero.grab(flag)} would be also ok. It 
does not have to be an expression. Similar for await.
II) Why no State RUNNING? In case heroGrab is shared between parallel 
processes I mean.
III) Who is the owner thread going to be? Is it really the best idea to 
use some unnamed thread pool to create the thread... or be always 
virtual? That is also a question that bothers me in the current proposal.


bye Jochen