On Sat, Mar 1, 2025, at 18:20, Rowan Tommins [IMSoP] wrote:
> On 01/03/2025 09:11, Edmond Dantes wrote:
> >
> > Good day, everyone. I hope you're doing well.
> >
> > I’d like to introduce a draft version of the RFC for the True Async
> > component.
> >
> > https://wiki.php.net/rfc/true_async
> >
>
> My reaction to this can be summed up as "this is huge!" By that I mean
> multiple things...
>
> First: PHP having native async support would be a huge step forward for
> the language. It's really exciting to see how this proposal develops.
>
> Second: it's clear you've put a huge amount of work into this, so a huge
> thank you for that, and I hope it is rewarded.
>
> Third: this is a huge proposal to digest. I wonder if there are ways it
> can be split into smaller pieces, so that we don't overlook details in
> one part because our focus is drawn to another. That might mean
> releasing a partial implementation this year, and more features next
> year; or it might just mean discussing and merging some core pieces
> first, then immediately following up with a series of feature RFCs, all
> targeting the same release.
>
> Fourth: design decisions here will have a huge impact on the language
> for years to come. We should spend plenty of time looking at experience
> from elsewhere - other languages, and existing third-party async
> implementations for PHP. This is closely related to the previous point,
> since expanding the current RFC with comparisons for every decision
> would make it impractically long.
>
> Fifth: this is a huge amount of new code - GitHub says 24 thousand lines
> of added code, although some of that is tests and documentation (which
> is great to see included!) We need to make sure there are enough people
> who understand the implementation to maintain that. Maybe we can try to
> tempt some of the core contributors to existing third-party libraries to
> spend some of their time on php-src instead.
>
>
> I realise I haven't actually given any concrete feedback on the proposal
> - I don't have any experience with other async implementations, and
> don't fully understand the concepts involved, so don't feel qualified to
> comment on the high-level design questions. I might have opinions on
> smaller design details (random example: RESOLVE, CANCEL, and TIMEOUT
> should be cases on an enum, not int constants) but see point 4: there's
> just too much here to discuss in that level of detail, and there are
> top-level decisions which should be our focus first.
>
> To re-iterate: this is really exciting, and thanks for getting it to
> this stage!
>
> --
> Rowan Tommins
> [IMSoP]
>
I second this, and as a long time user of amphp, go, and C#, I’d be coming into it with a specific
mindset.
My only thing so far is that it appears the scheduler cannot be replaced; at least, easily. I
don’t know if we would do so over on FrankenPHP, but it would be interesting to replace the
scheduler with something that utilized go-routines for true multi-threading. Whether that works or
not, is a whole different can of worms.
I’m compiling a deeper review, but that speaks more to the implementation than the spec.
— Rob