Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129280
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@mail.gmail.com>
 <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <CAMW7n8AX7O7x99KGdPSai6sPP1Xd6V4ojQ7CEWmxthNLPM2hyQ@mail.gmail.com>
 <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com> <CAMW7n8D3Mq6PveYxvfx=Djx6GnpkECOsEsEc2yKtJACAkAoLpQ@mail.gmail.com>
 <D0376B5C-7054-4948-BC48-5257F57B6129@zort.net> <CAEUnE0fcNP+R+r6rrMtUXcOYeCkutQzo-fTbkFpdL3VyLVXvQw@mail.gmail.com>
 <CADK1yXKS84aP9m=oExvL=rz2quGvXWKcPkV1h6gQj8vQUJjX3w@mail.gmail.com>
 <CAMW7n8ARHDQUeVKzsd44a11WGSuRm9CpvVK_D9YnBtMp9VxBSw@mail.gmail.com>
 <CADK1yXKsov2POUTrpzN+cKYk--H4kn6KmsMyUz_W7qfqEsCTQg@mail.gmail.com>
 <CAEUnE0fD0mqKv0PD+qbChmPj3btX4o-XyY9-qEJ_gW97EcX=Cw@mail.gmail.com> <713f2209-912d-41d3-8c1a-5015a7fb2166@app.fastmail.com>
In-Reply-To: <713f2209-912d-41d3-8c1a-5015a7fb2166@app.fastmail.com>
Date: Mon, 17 Nov 2025 16:16:39 +0100
Message-ID: <CAB9bCb0pXQ7N2s7PyvQZF8px0bnDN-dmZ1MdetYyBK86APp4aw@mail.gmail.com>
Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5)
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: bart+php@croquemonsieur.be (Bart Vanhoutte)

Hello everybody,

Long time lurker, first time poster here. I hope I've respected all
the rules as this is my first time posting on a mailing list,
apologies in advance if I haven't.

As someone who has been following this RFC since inception and as a
daily user of both sync PHP (Drupal) and async PHP (ReactPHP) I have a
couple of things I'd like to say. I'll leave out the technical things
for now and will keep it to the subject of governance.

It seems to me that the process that usually takes place when an RFC
is proposed is not compatible with an RFC of this size. This is not an
RFC to add a function that does something with arrays (all due
respect), the changes in the language and ecosystem in general are
profound. As this language is mainly developed by volunteers, I
understand that not everybody can allocate the time and mental
fortitude it takes to process an RFC like this. Hell, it took me quite
some time to rewire my brain from thinking synchronously to thinking
asynchronously while first developing applications using ReactPHP, I
can only imagine how daunting an RFC like this can be if you've rarely
or never developed an application this way, even if you are someone
who's contributed to the PHP language in the past.
What is clear to me is that currently, the amount of people who have
the right to vote and that have enough knowledge on this subject to be
able to judge whether or not this RFC should pass or fail is too low.
Moreover, even though there are quite a few people in the community
who have the knowledge required because they either develop or work
with aforementioned libraries or extensions, (almost) none of them
seem to be involved in discussing this RFC. For an RFC that can
drastically change the way we develop applications I would expect more
experts on this matter to be involved. Ideally, PHP core developers,
library developers & maintainers, IDE developers, ...,  would develop
software using this branch to at least get some feel for the paradigm
and this RFC in general.

I think Edmond has done a fantastic job developing this RFC but I
think an RFC of this size requires more resources, even if it just
means giving other PHP core developers the means to explore this topic
further. I feel like there is a big role to be played here by the PHP
Foundation to facilitate the development of a feature like this. I
hope this somehow gets picked up by them and that a working group or
something like that can be created that includes PHP core developers,
current async library maintainers, FIG-members, ..., so this RFC and
further related RFCs can be developed in a more structured (time &
money) way.

Best Regards,
Bart Vanhoutte

Op zo 16 nov 2025 om 21:28 schreef Larry Garfield <larry@garfieldtech.com>:
>
> On Sun, Nov 16, 2025, at 9:30 AM, Michael Morris wrote:
>
> > It would be nice to have a coordinator process that does all this setup
> > work and stays alive handling requests by handing them off to workers.
> > That's how the various C# apps I've seen work. But that sort of setup
> > would require asynchronous code. So I can see a future use case for all
> > of this. But you don't need to convince me - I don't have a vote.
>
> Alternatively, this is exactly what FrankenPHP solves.  Bootstrap once, r=
un many times.  It doesn't require async to work, though it doesn't conflic=
t with it either.  Personally I think FrankenPHP offers a more compelling w=
ay forward for taking PHP to the next level as it requires less retooling t=
han async, but I am quite open to having both.
>
> > Just, don't give up and don't get frustrated. It's hard. You can still
> > read the Drupal discussion on runtime assertions. I got rather testy at
> > times after explaining the same thing for the 12th time. But I didn't
> > take it personal and when my emotions needed checking I'd step away for
> > a few hours.
>
> Oh dear, I remember those discussions. :-)  And yes, the biggest thing I =
learned from Drupal 8 is that *no one reads the <censored> plan*, and you h=
ave to explain it to everyone individually, personally, several times, even=
 though you'd expect smart people to be able to *read the damned blog post =
that outlined the whole plan*, but they of course did not.
>
> --Larry Garfield
>
> PS: Please remember to bottom-post, not top post.