Thanks for the feedback Christopher. Can you give an example of what you'd like to achieve? I think I know what you mean but want to be sure.
Paul. On Thu, Apr 2, 2026 at 8:37 PM Christopher Smith <[email protected]> wrote: > > One thing I've been meaning to attempt but have not had the bandwidth is to > update the built-in extensive methods (mostly DefaultGroovyMethods) with > overloads that accept the JDK functional interfaces instead of Closure. With > the strong adoption of functional features by many libraries, the impedance > mismatch of not being able to feed those functions to (for example) `collect` > is both a dev and performance drag. > > Christopher Smith > > On Thu, Apr 2, 2026, 04:08 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
