Thanks Rémi, we'll have a re-think. On Thu, Apr 2, 2026 at 7:08 PM Remi Forax <[email protected]> wrote:
> ----- Original Message ----- > > From: "Paul King" <[email protected]> > > To: [email protected], "Groovy_Developers" <[email protected]> > > Cc: [email protected], "dev" <[email protected]> > > Sent: Thursday, April 2, 2026 7:52:18 AM > > Subject: Feedback requested for Groovy 6 > > > Hi folks, > > > > We are nearing time to do an alpha-1 release of Groovy 6. Thanks to > > the Groovy dev team and all users giving feedback for working on, or > > helping us shape, this new version. > > > > We are seeking feedback from users and other framework writers in the > > Groovy ecosystem for any features you would like to see in Groovy 6, > > and on the ones we have been looking to include. We can't always say > > "yes" to all feature proposals, but we are always keen on having > > discussions. > > > > You can have a quick look at the very draft release notes: > > > > https://groovy-lang.org/releasenotes/groovy-6.0.html > > > > We also published a series of blog posts over the last couple of weeks > > seeking feedback on potential features. > > [...] > > > > > 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". > > There is a need for async being easy in Groovy, but not based on a design > similar to completable future. > 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. > > [...] > > > > > Thanks, Paul. > > regards, > Rémi >
