Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129324
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 20 Nov 2025 12:54:44 +0100
To: internals@lists.php.net
Message-ID: <95dc52ad-7d6e-48a7-9edd-3060103f5a38@app.fastmail.com>
In-Reply-To: <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
References: 
 <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <C58ADF49-6E21-4E25-8859-2A0769829E38@php.net>
 <e8625214-1c6f-40b8-b24f-e592e6f92012@beccati.com>
 <CAMW7n8Dy3=QyCrG4BMwVXWAipgOr2Vyhy_jbLVTYeq2Jc5v15g@mail.gmail.com>
 <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk>
 <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
Content-Type: multipart/alternative;
 boundary=53795b54e1324bd6b3603990ddc1ce03
From: rob@bottled.codes ("Rob Landers")

--53795b54e1324bd6b3603990ddc1ce03
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Nov 20, 2025, at 11:18, Daniil Gentili wrote:
> Hi,
>=20
> >> Hello Bart.
> >> I am ready to agree with every word.
> >>
> >> Participation from a working group, framework representatives, and =
the
> >> ability to adapt libraries in advance would remove the concerns that
> >> are currently causing fear. This is probably the only effective
> >> process for developing and introducing such a feature.
> >
> > Then two days later, you decided that no more discussion was=20
> > necessary, and opened a vote.
> >
> > This feels like a complete contradiction.
> >
> > Let's find a way to get that working group set up, and get people fr=
om=20
> > other projects involved.
> >
>=20
> My key takeaway from Bart's message is:
>=20
> > Moreover, even though there are quite a few people in the community=20
> who have the knowledge required because they either develop or work wi=
th=20
> aforementioned libraries or extensions, (almost) none of them seem to =
be=20
> involved in discussing this RFC.
> > For an RFC that can drastically change the way we develop=20
> applications I would expect more experts on this matter to be involved=
.=20
> Ideally, PHP core developers, library developers & maintainers, IDE=20
> developers, ..., would develop software using this branch to at least=20
> get some feel for the paradigm and this RFC in general.
>=20
> I absolutely agree with this take, however, so far, the discussion=20
> around this RFC has been, in my opinion, mostly bikeshedding, with=20
> theoretical correctness proposals that are an absolute nightmare in=20
> practice (like structured concurrency), proposed by people that=20
> admittedly have never written extensive amounts of async code in=20
> languages using multiple paradigms, and thus haven't:
>=20
> - Experienced the pain of writing async with colored functions
> - Experienced the footguns of structured concurrency
> - And on the other hand, haven't experienced the pleasure and simplici=
ty=20
> of safely writing async code in languages like Go, or in PHP using AMP=
HP=20
> (which use uncolored and unstructured concurrency, the kind proposed a=
nd=20
> championed by edmond)
>=20
> While a working group *can* steer the conversation away from=20
> theoretically correct but practically unusable approaches, that can=20
> happen only if
>=20
> - The correct people (i.e. async library maintainers, or people that=20
> write async logic every day in multiple languages like myself) are pre=
sent
> - They are given more weight than the average PHP developer who hasn't=20
> used async much if at all, and can only make theoretical proposals not=20
> based on practice and experience
>=20
> I'm afraid that given the current state of the PHP community, which is=20
> largely new to async, the quality of the conversation in a working gro=
up=20
> would not be much higher than the one I'm seeing in this RFC, and woul=
d=20
> just protract even longer the agony of design by committee, where in=20
> reality what's needed is a single, clear and correct vision (which=20
> Edmond has), without influences from unexperienced people making=20
> proposals based purely on abstract/theoretical PoVs.
>=20
> Regards,
>=20
> Daniil Gentili.

I kind of take offence to this statement. First of all, I work almost ex=
clusively in Go these days, and on FrankenPHP. I only brought up colored=
 functions twice, because literally every language that has attempted th=
e proposed solution here have all reversed course and implemented colour=
ed functions. I've hand-written schedulers in C# (which is also cooperat=
ively scheduled).

Second, Go has a tremendous amount of primitives for dealing with concur=
rency: wait groups, locks, atomics, etc. This proposal has none of that,=
 hence my concern with suspension points.

Further, I have worked with AMPHP extensively since it's generator-based=
 days on multiple projects, and with Fibers quite extensively as well. S=
o saying "proposed by people that admittedly have never written extensiv=
e amounts of async code in languages using multiple paradigms" is factua=
lly untrue.

=E2=80=94 Rob
--53795b54e1324bd6b3603990ddc1ce03
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Thu, Nov 20, 2025, at 11:18, Daniil Gentili wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi,</div><div><=
br></div><div>&gt;&gt; Hello Bart.</div><div>&gt;&gt; I am ready to agre=
e with every word.</div><div>&gt;&gt;</div><div>&gt;&gt; Participation f=
rom a working group, framework representatives, and the</div><div>&gt;&g=
t; ability to adapt libraries in advance would remove the concerns that<=
/div><div>&gt;&gt; are currently causing fear. This is probably the only=
 effective</div><div>&gt;&gt; process for developing and introducing suc=
h a feature.</div><div>&gt;</div><div>&gt; Then two days later, you deci=
ded that no more discussion was&nbsp;</div><div>&gt; necessary, and open=
ed a vote.</div><div>&gt;</div><div>&gt; This feels like a complete cont=
radiction.</div><div>&gt;</div><div>&gt; Let's find a way to get that wo=
rking group set up, and get people from&nbsp;</div><div>&gt; other proje=
cts involved.</div><div>&gt;</div><div><br></div><div>My key takeaway fr=
om Bart's message is:</div><div><br></div><div>&gt; Moreover, even thoug=
h there are quite a few people in the community&nbsp;</div><div>who have=
 the knowledge required because they either develop or work with&nbsp;</=
div><div>aforementioned libraries or extensions, (almost) none of them s=
eem to be&nbsp;</div><div>involved in discussing this RFC.</div><div>&gt=
; For an RFC that can drastically change the way we develop&nbsp;</div><=
div>applications I would expect more experts on this matter to be involv=
ed.&nbsp;</div><div>Ideally, PHP core developers, library developers &am=
p; maintainers, IDE&nbsp;</div><div>developers, ..., would develop softw=
are using this branch to at least&nbsp;</div><div>get some feel for the =
paradigm and this RFC in general.</div><div><br></div><div>I absolutely =
agree with this take, however, so far, the discussion&nbsp;</div><div>ar=
ound this RFC has been, in my opinion, mostly bikeshedding, with&nbsp;</=
div><div>theoretical correctness proposals that are an absolute nightmar=
e in&nbsp;</div><div>practice (like structured concurrency), proposed by=
 people that&nbsp;</div><div>admittedly have never written extensive amo=
unts of async code in&nbsp;</div><div>languages using multiple paradigms=
, and thus haven't:</div><div><br></div><div>- Experienced the pain of w=
riting async with colored functions</div><div>- Experienced the footguns=
 of structured concurrency</div><div>- And on the other hand, haven't ex=
perienced the pleasure and simplicity&nbsp;</div><div>of safely writing =
async code in languages like Go, or in PHP using AMPHP&nbsp;</div><div>(=
which use uncolored and unstructured concurrency, the kind proposed and&=
nbsp;</div><div>championed by edmond)</div><div><br></div><div>While a w=
orking group *can* steer the conversation away from&nbsp;</div><div>theo=
retically correct but practically unusable approaches, that can&nbsp;</d=
iv><div>happen only if</div><div><br></div><div>- The correct people (i.=
e. async library maintainers, or people that&nbsp;</div><div>write async=
 logic every day in multiple languages like myself) are present</div><di=
v>- They are given more weight than the average PHP developer who hasn't=
&nbsp;</div><div>used async much if at all, and can only make theoretica=
l proposals not&nbsp;</div><div>based on practice and experience</div><d=
iv><br></div><div>I'm afraid that given the current state of the PHP com=
munity, which is&nbsp;</div><div>largely new to async, the quality of th=
e conversation in a working group&nbsp;</div><div>would not be much high=
er than the one I'm seeing in this RFC, and would&nbsp;</div><div>just p=
rotract even longer the agony of design by committee, where in&nbsp;</di=
v><div>reality what's needed is a single, clear and correct vision (whic=
h&nbsp;</div><div>Edmond has), without influences from unexperienced peo=
ple making&nbsp;</div><div>proposals based purely on abstract/theoretica=
l PoVs.</div><div><br></div><div>Regards,</div><div><br></div><div>Danii=
l Gentili.</div></blockquote><div><br></div><div>I kind of take offence =
to this statement. First of all, I work almost exclusively in Go these d=
ays, and on FrankenPHP. I only brought up colored functions twice, becau=
se literally every language that has attempted the proposed solution her=
e have all reversed course and implemented coloured functions. I've hand=
-written schedulers in C# (which is also cooperatively scheduled).</div>=
<div><br></div><div>Second, Go has a tremendous amount of primitives for=
 dealing with concurrency: wait groups, locks, atomics, etc. This propos=
al has none of that, hence my concern with suspension points.</div><div>=
<br></div><div>Further, I have worked with AMPHP extensively since it's =
generator-based days on multiple projects, and with Fibers quite extensi=
vely as well. So saying "proposed by people that&nbsp;admittedly have ne=
ver written extensive amounts of async code in&nbsp;languages using mult=
iple paradigms" is factually untrue.<br></div><div><br></div><div id=3D"=
sig121229152">=E2=80=94 Rob</div></body></html>
--53795b54e1324bd6b3603990ddc1ce03--