----- 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
