Re: Feedback requested for Groovy 6
Paul King <[email protected]> Sat, 4 Apr 2026 04:54:14 +1000
| Newsgroups | gmane.comp.lang.groovy.user |
|---|---|
| Message-ID | <CAMbkE7TP+_ee=bWkU8Ui_=TKHT+76sDo11EY01osZjik+NGbaw@mail.gmail.com> |
--000000000000942b06064e92d829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks R=C3=A9mi, we'll have a re-think. On Thu, Apr 2, 2026 at 7:08=E2=80=AFPM Remi Forax <[email protected]> wrote= : > ----- Original Message ----- > > From: "Paul King" <[email protected]> > > To: users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected], "Groovy_Developers" <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]= > > > Cc: geb-users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected], "dev" <dev-FvxHgLy0BgRd/SJB6HiN2Ni2O/[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 to= o > easy, you have no stacktrace so when an error occurs, you are lost, you c= an > 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 i= t, > you continue. > > This proposal does not groove me, it's syntactic sugar on top of a "Futur= e > 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 =3D async hero.grab(flag) // a Task object with = a > volatile state typed State :=3D 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 =3D async villain.grab(flag) > > var winner =3D 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 i= s > 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=C3=A9mi > --000000000000942b06064e92d829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks R=C3=A9mi, we'll have a re-think.</div><br><div= class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmai= l_attr">On Thu, Apr 2, 2026 at 7:08=E2=80=AFPM Remi Forax <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:<br></div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex">----- Original Message -----<br> > From: "Paul King" <<a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>><br> > To: <a href=3D"mailto:users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]" target=3D"_blank">users= @groovy.apache.org</a>, "Groovy_Developers" <<a href=3D"mailto= :dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]" target=3D"_blank">dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]</a>><br> > Cc: <a href=3D"mailto:geb-users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]" target=3D"_blank">g= eb-users-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]</a>, "dev" <<a href=3D"mailto:dev@g= rails.apache.org" target=3D"_blank">dev-FvxHgLy0BgRd/SJB6HiN2Ni2O/[email protected]</a>><br> > Sent: Thursday, April 2, 2026 7:52:18 AM<br> > Subject: Feedback requested for Groovy 6<br> <br> > Hi folks,<br> > <br> > We are nearing time to do an alpha-1 release of Groovy 6. Thanks to<br= > > the Groovy dev team and all users giving feedback for working on, or<b= r> > helping us shape, this new version.<br> > <br> > We are seeking feedback from users and other framework writers in the<= br> > Groovy ecosystem for any features you would like to see in Groovy 6,<b= r> > and on the ones we have been looking to include. We can't always s= ay<br> > "yes" to all feature proposals, but we are always keen on ha= ving<br> > discussions.<br> > <br> > You can have a quick look at the very draft release notes:<br> > <br> > <a href=3D"https://groovy-lang.org/releasenotes/groovy-6.0.html" rel= =3D"noreferrer" target=3D"_blank">https://groovy-lang.org/releasenotes/groo= vy-6.0.html</a><br> > <br> > We also published a series of blog posts over the last couple of weeks= <br> > seeking feedback on potential features.<br> <br> [...]<br> <br> > <br> > <a href=3D"https://groovy.apache.org/blog/groovy-async-await" rel=3D"n= oreferrer" target=3D"_blank">https://groovy.apache.org/blog/groovy-async-aw= ait</a><br> > <br> > Inspired by similar constructs in JavaScript, C#, Kotlin, and Swift,<b= r> > the proposal lets you write asynchronous code in a sequential,<br> > readable style. This allows developers to leverage virtual threads on<= br> > our compute environments, which have ever increasing processing power,= <br> > but without the complexity of writing ad-hoc multi-threaded code.<br> > (This is quite mature and ready for merging but hasn't seen widesp= read<br> > testing outside a few folks in the development team)<br> <br> Hello Paul,<br> I think you reach peak complexity (as Brian Goetz would say) with this feat= ure.<br> <br> There are 3 problems with CompletableFeature,<br> 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, y= ou are lost.<br> <br> 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.<br> <br> This proposal does not groove me, it's syntactic sugar on top of a &quo= t;Future Closure".<br> <br> There is a need for async being easy in Groovy, but not based on a design s= imilar to completable future.<br> Early erlang / early Go design, with a transparent management of the except= ion / cancellation / timeout would be far better.<br> <br> Something like, an async keyword to create an asynchronous expression and a= await + all/any and timemout should be enough<br> <br> def captureTheFlag(hero, villain, flag) {<br> =C2=A0 var heroGrab=C2=A0 =C2=A0 =3D async hero.grab(flag)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 // a Task object with a volatile state typed State :=3D NON_STAR= TED | Success(V value) | Failure(Throwable t)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0// + an owner thread, so it can not be submitted= /awaited by more than one thread<br> =C2=A0 var villainGrab =3D async villain.grab(flag)<br> <br> =C2=A0 var winner =3D await 1s any(heroGrab, villainGrab) else "no win= ner"=C2=A0 =C2=A0 =C2=A0// run using virtual threads or not (an Execut= or)<br> <br> =C2=A0 print $heroGrab() // either the value or throw the exception thrown = by hero.grab() (or a runtime exception for NON_STARTED)<br> }<br> <br> The method captureTheFlag does not need to be flagged as "async",= there is no wrappring/rewriting to a completable future code<br> <br> <br> I think you should reconsider how to make async easy in Groovy, both in ter= ms of syntax but also in terms of what's happen at runtime.<br> <br> [...]<br> <br> > <br> > Thanks, Paul.<br> <br> regards,<br> R=C3=A9mi<br> </blockquote></div> --000000000000942b06064e92d829--