I am pleased to say that we have a revised async proposal. Feedback is welcome again:
The blog post has been updated: https://groovy.apache.org/blog/groovy-async-await It is still feature packed, but hopefully not quite at the "peak complexity" level. In particular, the simple cases are much simpler now. More details are in the source files: https://github.com/paulk-asert/groovy/blob/GROOVY_9381_6/src/spec/test/AsyncAwaitSpecTest.groovy https://github.com/paulk-asert/groovy/blob/GROOVY_9381_6/src/spec/doc/core-async-await.adoc GitHub doesn't support rendering those nicely (yes there's a 10 year old bug about that) but if you check out locally and peruse in your IDE you will have a nicer experience. Merged features for other things in Groovy 6.0 are in the draft release notes: https://groovy-lang.org/releasenotes/groovy-6.0.html Cheers, Paul. On Sat, Apr 4, 2026 at 4:54 AM Paul King <[email protected]> wrote: > > 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
