Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129865
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <9f2fb78d-143e-c84a-8243-97e0352497e4@php.net>
Date: Thu, 22 Jan 2026 18:38:38 +0200
Message-ID: <CAMW7n8CoH95Cb3yp6cQ07rmppD2guFXFNip4vHshNxOBp5-ngA@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7
To: Derick Rethans <derick@php.net>
Cc: Jakub Zelenka <bukka@php.net>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e72ab80648fcac4e"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000e72ab80648fcac4e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

https://tonybaloney.github.io/posts/why-isnt-python-async-more-popular.html

I would also recommend paying attention to an excellent article about
asynchrony in Python and its problems.

And next quotation:

FastAPI, the web framework that=E2=80=99s async from-the-ground-up grew in
popularity again from 29% to 38% share of the web frameworks for Python,
taking the #1 spot. It has over 100-million downloads a month. Considering
the big use-case for async is HTTP and network IO, having the #1 web
framework be an async one is a sign of asyncio=E2=80=99s success.

And this is despite the fact that there are various problems, such as code
splitting due to colored functions.

That=E2=80=99s a serious argument, isn=E2=80=99t it?

=D1=87=D1=82, 22 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 17:15 Derick Ret=
hans <derick@php.net>:

> On Thu, 22 Jan 2026, Edmond Dantes wrote:
>
> > > I don't like this experimental model or introducing API stability
> > > levels as it is confusing for users. It requires extra checking for
> > > users to do for each API (no one usually does it and with AI it will
> > > be even more problematic because it might not tell that the
> > > generated code uses experimental API). This would just become pain
> > > for user and I don't think it would be good for PHP.
> >
> > I think this is a good topic for discussion, and we could talk about
> > the pros and cons of a =E2=80=9Cnightly=E2=80=9D build. I could explain=
 how early
> > product delivery improves code quality.
> >
> > > That can be already done but it will never guarantee that the second
> > > vote will succeed.
>
> > It's OK!
> >
> > But at least I would know that the PHP community truly wants to make
> > the language asynchronous. I still don=E2=80=99t understand the answer =
to that
> > question. It seems to me: no.
>
> I think there is a difference between:
>
> 1. Make the PHP language wholly asynchronous
> 2. Add some (more) asynchronous functionality to PHP
>
> From this series of RFCs, I think you believe that 1 is needed, or
> perhaps *necessary*. On the other hand, I believe that most PHP
> developers are more interested in the second option =E2=80=94 run a few s=
low
> things in parallel.
>
> There have now been more than half a dozen variants of the RFC, and
> beyond the amount of work that you put in it, it also asks a lot of
> everybody else to read and understand.
>
> As somebody earlier in these threads explained, the subject matter is
> also not a simple one, and it requires deep understanding to be able to
> understand all the trade-offs and consequences.
>
> Implementing this project requires is a large undertaking, akin to the
> Unicode project (PHP 6). That project ultimiately failed because it
> ended up being too big, with too many trade-offs. Your "True Async"
> project additionally suffers from only having one main implementor.
>
> The Unicode issue got partly resolved by splitting it up into much
> smaller blocks, in the form of the intl extension, and now in the last
> few releases with better support for handling graphemes. We have seen
> the same for PFAs and other langauge additions =E2=80=94 this makes it mu=
ch
> easier to reason about that, and to get these features adopted.
>
> I have said this before, but for a large project like "True Async", you
> really ought to get a group of people together in a Working Group, to
> decide what *PHP users* would want this functionality for in a language
> focussed mainly on web applications.
>
> But you approach this from the other side, by wanting to make PHP itself
> an asynchronous language. I think doing such a large project, mainly by
> yourself as the sole designed and developer, is doomed to fail. It isn't
> something I would be confident about voting for, at least.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
>
> Author of Xdebug. Like it? Consider supporting me:
> https://xdebug.org/support
>
> mastodon: @derickr@phpc.social @xdebug@phpc.social

--000000000000e72ab80648fcac4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><a href=3D"https://tonybaloney.github.io/posts/why-isnt-p=
ython-async-more-popular.html">https://tonybaloney.github.io/posts/why-isnt=
-python-async-more-popular.html</a><div dir=3D"auto"><br></div><div dir=3D"=
auto">I would also recommend paying attention to an excellent article about=
 asynchrony in Python and its problems.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">And next quotation:</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">FastAPI, the web framework that=E2=80=99s async from-the-ground=
-up grew in popularity again from 29% to 38% share of the web frameworks fo=
r Python, taking the #1 spot. It has over 100-million downloads a month. Co=
nsidering the big use-case for async is HTTP and network IO, having the #1 =
web framework be an async one is a sign of asyncio=E2=80=99s success.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">And this is despite the fact =
that there are various problems, such as code splitting due to colored func=
tions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">That=E2=80=99s a =
serious argument, isn=E2=80=99t it?</div></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">=D1=87=D1=82=
, 22 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 17:15 Derick Rethans &lt;<a =
href=3D"mailto:derick@php.net">derick@php.net</a>&gt;:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">On Thu, 22 Jan 2026, Edmond Dantes wrote:<br>
<br>
&gt; &gt; I don&#39;t like this experimental model or introducing API stabi=
lity <br>
&gt; &gt; levels as it is confusing for users. It requires extra checking f=
or <br>
&gt; &gt; users to do for each API (no one usually does it and with AI it w=
ill <br>
&gt; &gt; be even more problematic because it might not tell that the <br>
&gt; &gt; generated code uses experimental API). This would just become pai=
n <br>
&gt; &gt; for user and I don&#39;t think it would be good for PHP.<br>
&gt; <br>
&gt; I think this is a good topic for discussion, and we could talk about <=
br>
&gt; the pros and cons of a =E2=80=9Cnightly=E2=80=9D build. I could explai=
n how early <br>
&gt; product delivery improves code quality.<br>
&gt; <br>
&gt; &gt; That can be already done but it will never guarantee that the sec=
ond <br>
&gt; &gt; vote will succeed.<br>
<br>
&gt; It&#39;s OK!<br>
&gt;<br>
&gt; But at least I would know that the PHP community truly wants to make <=
br>
&gt; the language asynchronous. I still don=E2=80=99t understand the answer=
 to that <br>
&gt; question. It seems to me: no.<br>
<br>
I think there is a difference between:<br>
<br>
1. Make the PHP language wholly asynchronous<br>
2. Add some (more) asynchronous functionality to PHP<br>
<br>
From this series of RFCs, I think you believe that 1 is needed, or <br>
perhaps *necessary*. On the other hand, I believe that most PHP <br>
developers are more interested in the second option =E2=80=94 run a few slo=
w <br>
things in parallel.<br>
<br>
There have now been more than half a dozen variants of the RFC, and <br>
beyond the amount of work that you put in it, it also asks a lot of <br>
everybody else to read and understand.<br>
<br>
As somebody earlier in these threads explained, the subject matter is <br>
also not a simple one, and it requires deep understanding to be able to <br=
>
understand all the trade-offs and consequences.<br>
<br>
Implementing this project requires is a large undertaking, akin to the <br>
Unicode project (PHP 6). That project ultimiately failed because it <br>
ended up being too big, with too many trade-offs. Your &quot;True Async&quo=
t; <br>
project additionally suffers from only having one main implementor.<br>
<br>
The Unicode issue got partly resolved by splitting it up into much <br>
smaller blocks, in the form of the intl extension, and now in the last <br>
few releases with better support for handling graphemes. We have seen <br>
the same for PFAs and other langauge additions =E2=80=94 this makes it much=
 <br>
easier to reason about that, and to get these features adopted.<br>
<br>
I have said this before, but for a large project like &quot;True Async&quot=
;, you <br>
really ought to get a group of people together in a Working Group, to <br>
decide what *PHP users* would want this functionality for in a language <br=
>
focussed mainly on web applications.<br>
<br>
But you approach this from the other side, by wanting to make PHP itself <b=
r>
an asynchronous language. I think doing such a large project, mainly by <br=
>
yourself as the sole designed and developer, is doomed to fail. It isn&#39;=
t <br>
something I would be confident about voting for, at least.<br>
<br>
cheers,<br>
Derick<br>
<br>
-- <br>
<a href=3D"https://derickrethans.nl" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://derickrethans.nl</a> | <a href=3D"https://xdebug.org" r=
el=3D"noreferrer noreferrer" target=3D"_blank">https://xdebug.org</a> | <a =
href=3D"https://dram.io" rel=3D"noreferrer noreferrer" target=3D"_blank">ht=
tps://dram.io</a><br>
<br>
Author of Xdebug. Like it? Consider supporting me: <a href=3D"https://xdebu=
g.org/support" rel=3D"noreferrer noreferrer" target=3D"_blank">https://xdeb=
ug.org/support</a><br>
<br>
mastodon: @derickr@phpc.social @xdebug@phpc.social</blockquote></div>

--000000000000e72ab80648fcac4e--