Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129899
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 23 Jan 2026 10:41:35 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <213a47c7-cb2e-4d5c-b26b-ce18e3ce6d00@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8C=87rrzxH4n=_XKkVhmxG731cdnsfF-ujYs1ko-O=j9w@mail.gmail.com>
References: 
 <CAMW7n8B9XHzF5ND21-hNYtw26EnE+0b+W0Nv=wb_ayMmu4CbKw@mail.gmail.com>
 <CAMW7n8C1m08+pKKYBGkMnNZmGmu-_kkxS-r_SCuRupBY+RHe5A@mail.gmail.com>
 <CANCsWvfXWDjdmKFFQvV0Ger6yNVSfOhQqnbyTr7bEQHSjmXyLg@mail.gmail.com>
 <79CDB2CC-E397-436E-B5A2-10DA1E451A97@rwec.co.uk>
 <CAMW7n8BJcC-X-sA0NB_oQLfzry+331TfO1uhvNDGZcoSxe7bFQ@mail.gmail.com>
 <D427F18D-CDEC-4DDE-8169-71F8156F2E48@rwec.co.uk>
 <CAMW7n8BjxUUiizXbD1Lb526WsV=6erew-rK70gvMoWoQ2sqDmQ@mail.gmail.com>
 <CADK1yX+fA2epqOn2rcesmVBZMj4taeARhyuNdTky9aH4B6NhWg@mail.gmail.com>
 <CAMW7n8ALJ2w7iSwVX1TvyiosN_dzj=0NV0XBRZeQ3Hdov98C6Q@mail.gmail.com>
 <CAEKnhAFbU5H3qs-s0_FsT6w1Bu8n6HD+BQRt1SoOCUwa3XtT_w@mail.gmail.com>
 <CAMW7n8CFOafm21nbzPRx35ZXKzi-B0WC+7=X7dJMT=f=GDan-g@mail.gmail.com>
 <9f2fb78d-143e-c84a-8243-97e0352497e4@php.net>
 <CAMW7n8C41JB14qNM9SqjUEk3_nYMegMqUywR2if6g0YCLKFZ+g@mail.gmail.com>
 <9d2962b9-2278-4fae-9241-9def0f33711f@app.fastmail.com>
 <CAMW7n8C=87rrzxH4n=_XKkVhmxG731cdnsfF-ujYs1ko-O=j9w@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 23, 2026, at 6:04 AM, Edmond Dantes wrote:
> Hello.
>
>> I don=E2=80=99t think that=E2=80=99s universally true, or at least it=
 hasn=E2=80=99t been my experience.
> As far as I know, there is no universal truth. PHP plus asynchronicity
> plus a crisis of trust is a very specific situation.
> And it has existed longer than this RFC. It=E2=80=99s a fairly large t=
opic for
> discussion, and probably uncomfortable.
>
>> When I personally stepped back
> Lately, I=E2=80=99ve been hearing the phrase =E2=80=9Ctake a step back=
=E2=80=9D quite a few times.
> But believe me, not a single person who=E2=80=99s said this to me has =
been
> able to clearly explain what they actually mean.
> What does =E2=80=9Ca step back=E2=80=9D even mean?
>
>> I want to be clear about something important, though: this isn=E2=80=99=
t a lack of interest in asynchronous capabilities in PHP, nor a lack of =
willingness to help.
>
> * Python got asynchronicity in 2015.
> * Python is a general-purpose language, and asynchronous I/O is not a
> critical feature for it.
> * PHP still hasn=E2=80=99t gained asynchronicity. It=E2=80=99s 2026.
> * For PHP, asynchronicity matters more than it does for Python.
>
> On top of that, there have been some attempts by different people to
> add asynchronicity to PHP, all of which either failed or were ignored.
> So there is interest in asynchronicity, but it seems to be buried
> very, very deep :)
>
>> contributors need to feel that concerns are being heard, trade-offs a=
re being explored together, and iteration is genuinely collaborative.
>
> * What concerns?
> * What collaboration?
> What is this actually about?
>
> Everyone who wanted to collaborate on this RFC has already done so.
> I=E2=80=99m running this project 100% openly, there isn=E2=80=99t even=
 a private chat.
> Only a few ideas were discussed privately over email, and I always
> write about the outcomes of those discussions publicly.
>
>> If the process moves in that direction, breaking things down, explici=
tly engaging with criticism, and evolving the design based on shared inp=
ut, I think you may find that more people are willing to invest time and=
 energy into it.
>
> Sorry, but I don=E2=80=99t understand anything from this sentence at a=
ll:
> * Which direction? What=E2=80=99s wrong with the current one?
> * Into what parts should things be broken down, and why?
> * What does =E2=80=9Cexplicitly engaging with criticism=E2=80=9D mean?=
 And what kind
> of work was being done before. Implicit? Hidden?
> * What does =E2=80=9Cevolving the design based on shared input=E2=80=9D=
 mean? Who is
> stopping you from contributing to an open repository? Who is this
> person who is forbidding it? Tell us who they are and we=E2=80=99ll pu=
nish
> them :)
>
> And you seem to be missing the most important point:
> * this project is not something I personally need.
> * It=E2=80=99s not my project that people aren=E2=80=99t joining.
> * The TrueAsync project was created first and foremost for PHP itself.
> * PHP is the one that needs it.
>
> I am already an experienced and fully capable developer without it. I
> don=E2=80=99t need to prove anything to anyone.
> The problems with the process of accepting large changes to the
> language cannot be solved by me. They are outside the scope of my
> responsibility.
> I don=E2=80=99t need to solve it. I don=E2=80=99t need to create worki=
ng groups. I
> don=E2=80=99t need to write private emails and ask everyone to vote. I=
=E2=80=99ve
> already done the work within the scope of the responsibility.
>
> The remaining percentage of success no longer depends on my actions.

I've not had a chance to look at the latest draft yet, but I do want to =
speak to the process debate.

There's multiple overlapping problems/challenges here, and we need to se=
parate them.

1. This proposal is *huge*, and subsequent drafts are often very heavily=
 modified, so that means people need to spend an hour or two each time t=
here's a change fully digesting it.  That's a very large ask, especially=
 when there are exactly 0 people in the world who have "review RFCs" as =
their job description; not even the Foundation team has that, technicall=
y.  I've worked on some very large RFCs (hooks), so I know the challenge=
 this poses, but Async is even worse because it's more conceptually comp=
lex and far reaching.

This is exacerbated by, I suspect, a language barrier issue, which comes=
 off as Ed being dismissive of feedback.  But regardless of the cause, t=
here are definitely people who feel their concerns have been dismissed (=
rightly or wrongly).  I know I spent many hours reading and responding t=
o earlier drafts a year ago, and I know some of that feedback still hasn=
't been incorporated.

2. Because it's so complex, we get a strong reverse-bikeshed problem.  T=
his is a nuclear-reactor level feature, not a bikeshed level feature, so=
 fairly few people even feel qualified to critique the specifics, whethe=
r they have the time to or not.

3. PHP is a structureless organization.  That means we suffer from the T=
yranny of Structurelessness[1].  (Please everyone, do read that article.=
  It takes less time than reading the Async RFC. :-) )  It's not that PH=
P has no leadership, it's that the leadership is an informal amorphous b=
lob with no clear definition, and everyone has a different idea of who i=
t is.

8 years ago, there was a de facto consensus that Nikita was The Lead(tm)=
, and so if Nikita liked something it would probably pass because people=
 trusted Nikita, and if Nikita didn't like something it would probably n=
ot pass because people trusted Nikita.  Nikita was a known quantity, and=
 people trusted his judgement, even if they didn't always understand it.=
  So Nikita's RFCs almost always passed.  (Whether you consider that goo=
d or bad is a separate matter.)

Today, there's about a half dozen people that have maybe a quarter of th=
at clout.  Of course, there's no consensus on exactly who those people a=
re.  It probably overlaps heavily with the Foundation staff, but not ent=
irely.  But that means there's no one who can "bless" this RFC to give e=
veryone else confidence that the adults in the room, the PHP elites if y=
ou will, think it's OK.

That's what's really missing from this RFC: Quite simply, Ed is an unkno=
wn quantity.  This is his first RFC, and it's a doozy.  If the exact sam=
e RFC were proposed by, for example, a team of Ilija, Arnaud, Tim, and D=
erick, it would likely get a much warmer reception and attention.  Not b=
ecause those people are "better developers" than Ed, but because they ha=
ve a track record, cloud, and "street cred" that Ed simply does not.

Naturally, your list of who has that kind of "cloud" will be different f=
rom mine; that is the problem of a structureless organization.

If Ed had been partnering with one of those "elites" all along, or broug=
ht one in part way through to vet and approve things, the RFC itself wou=
ld probably be stronger but also more palatable.

*That* is what the various requests for a working group were about.  Not=
 "go elsewhere and talk to a bunch of people who never post on the Inter=
nals list to get their buy-in."  That may be technically useful (and it =
seems like it was), but it's not politically or socially useful.  What i=
s lacking is "the people who are visible in Internals that I trust to sw=
eat the details are on the job, and they're on board, so I feel safe bei=
ng on board."

To be clear: This is not in any way shape or form Ed's fault.  This is 1=
000% a failure of PHP the project, and a direct consequence of the proje=
ct's steadfast refusal to introduce any sort of meaningful formal struct=
ure.  This is why some of us have been trying on and off for years to fi=
x this problem, but so far unsuccessfully.

What is really needed here, frankly, is for there to be more names on th=
e RFC, and more familiar names.  People who have the "street cred" to be=
 trusted, or that we know how to engage with.  People who are able to fo=
rm consensus.  That's what a working group means in this case: Having cl=
ear, dedicated, influential input into the design from people, both gene=
ralists and specialists, that others will trust to "get it right.."

Who those people should be, well, we're a structureless organization so =
I'm pretty sure everyone has a different list of names.

[1] https://www.jofreeman.com/joreen/tyranny.htm

--Larry Garfield