Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129272
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>
In-Reply-To: <CADK1yXKsov2POUTrpzN+cKYk--H4kn6KmsMyUz_W7qfqEsCTQg@mail.gmail.com>
Date: Sun, 16 Nov 2025 10:30:54 -0500
Message-ID: <CAEUnE0fD0mqKv0PD+qbChmPj3btX4o-XyY9-qEJ_gW97EcX=Cw@mail.gmail.com>
Subject: Re: A Thank you (was Re: [PHP-DEV] PHP True Async RFC Stage 5)
To: Deleu <deleugyn@gmail.com>
Cc: Edmond Dantes <edmond.ht@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000599d4a0643b7eb77"
From: tendoaki@gmail.com (Michael Morris)

--000000000000599d4a0643b7eb77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

100% agree with Deleu.

Edmond, part of the problem you're facing is you aren't just introducing a
new feature - you're introducing a paradigm shift. I did an RFC like that
once - the introduction of runtime assertions into Drupal - and the
discussion around the change took far, far longer than the code - about 6
months. The initial reaction was that such are unneeded in Drupal, after
all there's thousands of unit tests. I had to explain that unit tests are
for known configurations and that runtime assertions are for the
unknown, among other arguments for and against. The RFC was eventually
accepted because it provided a means to significantly speed up Drupal by
stepping over its development token sanity checks in prod, but it was a
stormy journey.

Coming back to your proposal, While I'm very aware of the async pattern
from its use in JavaScript and C#, I don't quite get where it will be
useful in PHP. My experience with PHP is that it responds to HTTP requests
and that stepping over a function that hasn't finished its output isn't
helpful because you aren't really saving any time in that request thread as
it has very defined start and end points. But we write PHP scripts the way
we do because of how the language is structured. Many apps spend a lot of
time setting up for the request - Drupal for example has to boot its
kernel and part of that is the reading in of an enormous dependency
injection map generated from the configuration yaml files of the active
modules - that file alone can get into tens of thousands of lines of code.
All of that processing work to just be thrown away once the echo back to
the server occurs.

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.

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=
.

Everyone, It might help to do an RFC just on the principle of adding
asynchronous code to 9 without commitment to any particular
implementation.  Unlike the lofty goal of adding unicode to the language
which never panned out and caused us to need to step over 6, Edmond's RFC
seems far enough along to prove that it is a doable change for the language
in some form. Such an RFC would get Edmond off the clock and relieve some
stress of feeling like "I've got to get this approved before the window to
submit closes." I know what that window feels like because the PHP runtime
assertions addition to Drupal 8 was dead last and only accepted because it
provided a solution to an issue blocking release. It would also get the
rest of us off the clock as well. This proposal needs very careful
consideration as it has wide ranging implications. But it's also the sort
of proposal that can't walk in on a minor release, and major release
windows are rare.

Again, thank you everyone.

On Sun, Nov 16, 2025 at 7:17=E2=80=AFAM Deleu <deleugyn@gmail.com> wrote:

> This thread is a clear, explicit and direct representation that there are
> people following all the hard work that you=E2=80=99ve put into this RFC.=
 I dare
> say that nobody doubts your intentions, effort and initiative to tackle
> such a complex and hard task.
>
> The next step is to recognize that anybody participating in an RFC
> discussion is a person taking time out of their lives, their family, thei=
r
> work, their hobbies and volunteering their time similar to you. Everyone
> has PHP best interest at heart even if what we think is best for PHP
> differs.
>
> On Sun, 16 Nov 2025 at 03:56 Edmond Dantes <edmond.ht@gmail.com> wrote:
>
>> Hello
>>
>> > Maybe that=E2=80=99s inherent to a subject matter that indeed could be=
 the
>> biggest change to PHP since 7,
>> > but given RFC voting history, all signs point to a rejection vote.
>>
>> I think so too.
>>
>> > I don=E2=80=99t know how much has been discussed off list and/or how m=
any
>> voters are involved off list.
>>
>> There were almost no discussions apart from the one on INTERNALS. I
>> mean, there were no discussions that I=E2=80=99m aware of.
>>
>> I don=E2=80=99t know what to do about a situation where PHP developers a=
re
>> surprised to learn that their language has supported transparent
>> asynchrony as a core paradigm for several years already.
>
>
> I suppose you=E2=80=99re referring to Swoole, AMPHP, ReactPHP, etc. While=
 there=E2=80=99s
> no denying they=E2=80=99re an important part of the ecosystem and living =
proof
> there=E2=80=99s room for asynchronous PHP, your positioning here seems to=
 assume
> that everybody participating in your RFC should know, understand and use
> one of these projects and have that baseline knowledge. From my personal
> experience, context and little bubble, I would guess that less than 10% o=
f
> PHP engineers worldwide has any firsthand experience with any of these
> tools combined. Your RFC can bridge that gap, but to do so you need to be
> able to address why the other 90% hasn=E2=80=99t used any of these existi=
ng
> approaches. Your target audience is exactly the opposite of what you expe=
ct.
>
>
>> And instead of discussing the important details of the RFC, all the
>> effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t w=
orth discussing at
>> all.
>
>
>
> This is perhaps the most likely reason for the RFC to fail a vote. Let=E2=
=80=99s
> break down voting in an abstract format. Some common reasons voters may
> choose to vote NO are:
>
> - they don=E2=80=99t like the change and don=E2=80=99t want it on PHP
> - they disagree with the approach
> - the change increases PHP maintenance burden for a subjective benefit
> - the RFC is unclear
>
> There=E2=80=99s not much you can do about 1. And for every NO you get, yo=
u need 2
> YES to overcome it.
>
> My personal guess is that 4 would drive a lot of NO and the reason is a
> combination of factors. It=E2=80=99s a very complex and dense RFC and not=
 every
> voter will have any experience with the existing async tools provided by
> the community. When trying to take time out of their personal lives to go
> through such a complex and extensive RFC, basic questions will arise. The=
y
> will attempt to address it before going deeper and deeper and will be met
> with a dismissive response from the author =E2=80=9Cbecause this is too b=
asic and
> we shouldn=E2=80=99t focus on it=E2=80=9D. They will make the easy choice=
 to not continue
> to volunteer their time into something so hard to wrap your head around
> since it=E2=80=99s too challenging to even get past the basics. A negativ=
e result
> is not really a surprise at this point.
>
> It would be wonderful if there were a dedicated person whom everyone
>> would listen to carefully and who could explain the basic questions
>> privately. Most likely, this approach would solve many problems.
>>
>> ---
>> Best Regards, Ed
>
>
> Short of forking PHP, that seems like wishful thinking. PHP is driven by
> committee and there doesn=E2=80=99t seem to be any way around that. But t=
here are
> approaches you can try.
>
> One of them is pairing it up with someone better at docs, communication,
> etc. Take a look at Larry=E2=80=99s RFCs. Majority of it he doesn=E2=80=
=99t write any C
> code, but he makes up for it 10 times by producing clearly readable,
> understandable and decision points communicated. Voters may still disagre=
e
> at the end, but it always feels like they understand what they=E2=80=99re=
 voting
> on/for.
>
> I don=E2=80=99t know if you=E2=80=99re good with a camera, but going in a=
 podcast with
> someone like Brandt, Nuno Maduro or any other PHP podcast that tries to
> breakdown internals for easy consumption could also help your cause.
>
> Ultimately, I think your vast expertise on the matter is both a blessing
> and a curse. A blessing because without it maybe the RFC would have never
> even existed - at least no other RFC on the matter has reached so far. A
> curse because nobody else seems to be able to understand what you=E2=80=
=99re
> saying, what you=E2=80=99re doing and what PHP will be like if your RFC i=
s approved.
>
> As someone writing PHP for 15 years, I=E2=80=99m scared of bringing any a=
sync
> community tools to any project I work because I don=E2=80=99t know what w=
ould
> break. Your RFC states that you want all my code to keep working which is
> great, but the moment I make use of something async it could inadvertentl=
y
> affect something and I don=E2=80=99t know what/why/how. I=E2=80=99m dumb =
and don=E2=80=99t know how
> async works and I don=E2=80=99t want PHP to allow me to shoot myself in t=
he head
> like that. Is there anything you can do about it?
>
> I wish you all the best luck on the RFC and your next steps. I thank you
> for all your time so far and I=E2=80=99m eager to see what come out of it=
.
>
>>

--000000000000599d4a0643b7eb77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">100% agree with Deleu.<br><div><br></div>=
<div>Edmond, part of the problem you&#39;re facing is you aren&#39;t just i=
ntroducing a new feature - you&#39;re introducing a paradigm shift. I did a=
n RFC like that once - the introduction of runtime assertions into Drupal -=
 and the discussion around the change took far, far longer than the code - =
about 6 months. The initial reaction was that such are unneeded in Drupal, =
after all there&#39;s thousands of unit tests. I had to explain that unit t=
ests are for known configurations and that runtime assertions are for the u=
nknown,=C2=A0among other=C2=A0arguments for and against. The RFC was eventu=
ally accepted because it provided a means to significantly speed up Drupal =
by stepping over its development token sanity checks in prod, but it was a =
stormy=C2=A0journey.</div><div><br></div><div>Coming back to your proposal,=
 While I&#39;m very aware of the async pattern from its use in JavaScript a=
nd C#, I don&#39;t quite get where it will be useful in PHP. My experience =
with PHP is that it responds to HTTP requests and that stepping over a func=
tion that hasn&#39;t finished its output isn&#39;t helpful because you aren=
&#39;t really saving any time in that request thread as it has very defined=
 start and end points. But we write PHP scripts the way we do because of ho=
w the language is structured. Many apps spend a lot of time setting up for =
the request - Drupal for example has to boot its kernel=C2=A0and part of th=
at is the reading in of an enormous dependency injection map generated from=
 the configuration yaml files of the active modules - that file alone can g=
et into tens of thousands of lines of code. All of that processing work to =
just be thrown away once the echo back to the server occurs.</div><div><br>=
</div><div>It would be nice to have a coordinator process that does all thi=
s setup work and stays alive handling requests by handing them off to worke=
rs. That&#39;s how the various C# apps I&#39;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&#39;t need to convince me - I don&#39;t have a vot=
e.</div><div><br></div><div>Just, don&#39;t give up and don&#39;t get frust=
rated. It&#39;s hard. You can still read the Drupal discussion on runtime a=
ssertions. I got rather testy=C2=A0at times after explaining the same thing=
 for the 12th time. But I didn&#39;t take it personal and when my emotions =
needed checking I&#39;d step away for a few hours.</div><div><br></div><div=
>Everyone, It might help to do an RFC just on the principle of adding async=
hronous code to 9 without commitment to any particular implementation.=C2=
=A0 Unlike the lofty goal of adding unicode to the language which never pan=
ned out and caused us to need to step over 6, Edmond&#39;s=C2=A0RFC seems f=
ar enough along to prove that it is a doable change for the language in som=
e form. Such an RFC would get Edmond off the clock and relieve some stress =
of feeling like &quot;I&#39;ve got to get this approved before the window t=
o submit closes.&quot; I know what that window feels like because the PHP r=
untime assertions addition to Drupal 8 was dead last and only accepted beca=
use it provided a solution to an issue blocking release. It would also get =
the rest of us off the clock as well. This proposal needs very careful cons=
ideration as it has wide ranging implications. But it&#39;s also the sort o=
f proposal that can&#39;t walk in on a minor release, and major release win=
dows are rare.</div><div><br></div><div>Again, thank you everyone.</div></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sun, Nov 16, 2025 at 7:17=E2=80=AFAM Deleu &lt;<a hre=
f=3D"mailto:deleugyn@gmail.com">deleugyn@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div><d=
iv dir=3D"auto" style=3D"font-size:16px;font-style:normal;font-weight:400;l=
etter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0);borde=
r-color:rgb(0,0,0);color:rgb(0,0,0)">This thread is a clear, explicit and d=
irect representation that there are people following all the hard work that=
 you=E2=80=99ve put into this RFC. I dare say that nobody doubts your inten=
tions,=C2=A0effort and initiative to tackle such a complex and hard task.</=
div><div dir=3D"auto" style=3D"font-size:16px;font-style:normal;font-weight=
:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:=
normal;word-spacing:0px;text-decoration:none;background-color:rgba(0,0,0,0)=
;border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir=3D"auto" styl=
e=3D"font-size:16px;font-style:normal;font-weight:400;letter-spacing:normal=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te=
xt-decoration:none;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);c=
olor:rgb(0,0,0)">The next step is to recognize that anybody participating i=
n an RFC discussion is a person taking time out of their lives, their famil=
y, their work, their hobbies and volunteering their time similar to you. Ev=
eryone has PHP best interest at heart even if what we think is best for PHP=
 differs.=C2=A0</div></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">On Sun, 16 Nov 2025 at 03:56 Edmond Dantes &lt;<a href=3D"mailto:edmond=
.ht@gmail.com" target=3D"_blank">edmond.ht@gmail.com</a>&gt; wrote:<br></di=
v><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" dir=3D"auto">Hello<br>
<br>
&gt; Maybe that=E2=80=99s inherent to a subject matter that indeed could be=
 the biggest change to PHP since 7,<br>
&gt; but given RFC voting history, all signs point to a rejection vote.<br>
<br>
I think so too.<br>
<br>
&gt; I don=E2=80=99t know how much has been discussed off list and/or how m=
any voters are involved off list.<br>
<br>
There were almost no discussions apart from the one on INTERNALS. I<br>
mean, there were no discussions that I=E2=80=99m aware of.<br>
<br>
I don=E2=80=99t know what to do about a situation where PHP developers are<=
br>
surprised to learn that their language has supported transparent<br>
asynchrony as a core paradigm for several years already.</blockquote><div d=
ir=3D"auto"><br></div><div dir=3D"auto">I suppose you=E2=80=99re referring =
to Swoole, AMPHP, ReactPHP, etc. While there=E2=80=99s no denying they=E2=
=80=99re an important part of the ecosystem and living proof there=E2=80=99=
s room for asynchronous PHP, your positioning here seems to assume that eve=
rybody participating in your RFC=C2=A0should know, understand and use one o=
f these projects and have that baseline knowledge. From my personal experie=
nce, context and little bubble, I would guess that less than 10% of PHP eng=
ineers worldwide has any firsthand experience with any of these tools combi=
ned. Your RFC can bridge that gap, but to do so you need to be able to addr=
ess why the other 90% hasn=E2=80=99t used any of these existing approaches.=
 Your target audience is exactly the opposite of what you expect.</div><div=
 dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" d=
ir=3D"auto"><br>
And instead of discussing the important details of the RFC, all the<br>
effort goes into =E2=80=9Cbasic questions=E2=80=9D that aren=E2=80=99t wort=
h discussing at<br>
all.</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">This is perhaps the most likely reason for the RFC to fail =
a vote. Let=E2=80=99s break down voting in an abstract format. Some common =
reasons voters may choose to vote NO are:</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">- they don=E2=80=99t like the change and don=E2=80=99t wa=
nt it on PHP</div><div dir=3D"auto">- they disagree with the approach</div>=
<div dir=3D"auto">- the change increases PHP maintenance burden for a subje=
ctive benefit</div><div dir=3D"auto">- the RFC is unclear</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">There=E2=80=99s not much you can do about=
 1. And for every NO you get, you need 2 YES to overcome it.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">My personal guess is that 4 would dri=
ve a lot of NO and the reason is a combination of factors. It=E2=80=99s a v=
ery complex and dense RFC and not every voter will have any experience with=
 the existing async tools provided by the community. When trying to take ti=
me out of their personal lives to go through such a complex and extensive R=
FC, basic questions will arise. They will attempt to address it before goin=
g deeper and deeper and will be met with a dismissive response from the aut=
hor =E2=80=9Cbecause this is too basic and we shouldn=E2=80=99t focus on it=
=E2=80=9D. They will make the easy choice to not continue to volunteer thei=
r time into something so hard to wrap your head around since it=E2=80=99s t=
oo challenging to even get past the basics. A negative result is not really=
 a surprise at this point.</div><div dir=3D"auto"><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex" dir=3D"auto">It would be wonderful if th=
ere were a dedicated person whom everyone<br>
would listen to carefully and who could explain the basic questions<br>
privately. Most likely, this approach would solve many problems.<br>
<br>
---<br>
Best Regards, Ed</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">=
Short of forking PHP, that seems like wishful thinking. PHP is driven by co=
mmittee and there doesn=E2=80=99t seem to be any way around that. But there=
 are approaches you can try.=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">One of them is pairing it up with someone better at docs, commun=
ication, etc. Take a look at Larry=E2=80=99s RFCs. Majority of it he doesn=
=E2=80=99t write any C code, but he makes up for it 10 times by producing c=
learly readable, understandable and decision points communicated. Voters ma=
y still disagree at the end, but it always feels like they understand what =
they=E2=80=99re voting on/for.=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">I don=E2=80=99t know if you=E2=80=99re good with a camera, but=
 going in a podcast with someone like Brandt, Nuno Maduro or any other PHP =
podcast that tries to breakdown internals for easy consumption could also h=
elp your cause.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ultimate=
ly, I think your vast expertise on the matter is both a blessing and a curs=
e. A blessing because without it maybe the RFC would have never even existe=
d - at least no other RFC on the matter has reached so far. A curse because=
 nobody else seems to be able to understand what you=E2=80=99re saying, wha=
t you=E2=80=99re doing and what PHP will be like if your RFC is approved.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">As someone writing PHP fo=
r 15 years, I=E2=80=99m scared of bringing any async community tools to any=
 project I work because I don=E2=80=99t know what would break. Your RFC sta=
tes that you want all my code to keep working which is great, but the momen=
t I make use of something async it could inadvertently affect something and=
 I don=E2=80=99t know what/why/how. I=E2=80=99m dumb and don=E2=80=99t know=
 how async works and I don=E2=80=99t want PHP to allow me to shoot myself i=
n the head like that. Is there anything you can do about it?</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I wish you all the best luck on the R=
FC and your next steps. I thank you for all your time so far and I=E2=80=99=
m eager to see what come out of it.</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" dir=3D"auto"></blockquote><div dir=3D"auto"></div></div></d=
iv>
</blockquote></div></div>

--000000000000599d4a0643b7eb77--