Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129850
Date: Thu, 22 Jan 2026 15:15:21 +0000 (GMT)
To: Edmond Dantes <edmond.ht@gmail.com>
cc: Jakub Zelenka <bukka@php.net>, php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7
In-Reply-To: <CAMW7n8CFOafm21nbzPRx35ZXKzi-B0WC+7=X7dJMT=f=GDan-g@mail.gmail.com>
Message-ID: <9f2fb78d-143e-c84a-8243-97e0352497e4@php.net>
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>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1646125595-1769094921=:924205"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1646125595-1769094921=:924205
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 22 Jan 2026, Edmond Dantes wrote:

> > I don't like this experimental model or introducing API stability=20
> > levels as it is confusing for users. It requires extra checking for=20
> > users to do for each API (no one usually does it and with AI it will=20
> > be even more problematic because it might not tell that the=20
> > generated code uses experimental API). This would just become pain=20
> > for user and I don't think it would be good for PHP.
>=20
> I think this is a good topic for discussion, and we could talk about=20
> the pros and cons of a =E2=80=9Cnightly=E2=80=9D build. I could explain h=
ow early=20
> product delivery improves code quality.
>=20
> > That can be already done but it will never guarantee that the second=20
> > vote will succeed.

> It's OK!
>
> But at least I would know that the PHP community truly wants to make=20
> the language asynchronous. I still don=E2=80=99t understand the answer to=
 that=20
> 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=20this series of RFCs, I think you believe that 1 is needed, or=20
perhaps *necessary*. On the other hand, I believe that most PHP=20
developers are more interested in the second option =E2=80=94 run a few slo=
w=20
things in parallel.

There have now been more than half a dozen variants of the RFC, and=20
beyond the amount of work that you put in it, it also asks a lot of=20
everybody else to read and understand.

As somebody earlier in these threads explained, the subject matter is=20
also not a simple one, and it requires deep understanding to be able to=20
understand all the trade-offs and consequences.

Implementing this project requires is a large undertaking, akin to the=20
Unicode project (PHP 6). That project ultimiately failed because it=20
ended up being too big, with too many trade-offs. Your "True Async"=20
project additionally suffers from only having one main implementor.

The Unicode issue got partly resolved by splitting it up into much=20
smaller blocks, in the form of the intl extension, and now in the last=20
few releases with better support for handling graphemes. We have seen=20
the same for PFAs and other langauge additions =E2=80=94 this makes it much=
=20
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=20
really ought to get a group of people together in a Working Group, to=20
decide what *PHP users* would want this functionality for in a language=20
focussed mainly on web applications.

But you approach this from the other side, by wanting to make PHP itself=20
an asynchronous language. I think doing such a large project, mainly by=20
yourself as the sole designed and developer, is doomed to fail. It isn't=20
something I would be confident about voting for, at least.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1646125595-1769094921=:924205--