Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129816
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>
In-Reply-To: <79CDB2CC-E397-436E-B5A2-10DA1E451A97@rwec.co.uk>
Date: Wed, 21 Jan 2026 19:13:34 +0200
Message-ID: <CAMW7n8BJcC-X-sA0NB_oQLfzry+331TfO1uhvNDGZcoSxe7bFQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

> The idea of a "working group" was discussed, but no process was establish=
ed, no "charter", no milestones. Edmond has been doing an amazing amount of=
 work,
> and I will repeat that I have huge respect for that effort. But if you dr=
op an encyclopedia on someone's desk and say "discuss", is it really surpri=
sing that people don't know what to say?

As for the working group, it was created.
AMPHP and Swoole officially responded to the proposal.
Most of the discussions took place publicly.

We can read them here:
https://github.com/true-async/php-true-async-rfc/discussions

I thought there would be more discussions, but the thing is that we
don=E2=80=99t have any serious disagreements about the architecture.
There are some doubts that the RFC won=E2=80=99t be accepted in its entiret=
y,
but that=E2=80=99s not a disagreement, rather secondary issues.
This situation is largely expected, because this RFC doesn=E2=80=99t propos=
e
something new, but rather suggests bringing into the PHP core what has
long been working in the form of "extensions".
That=E2=80=99s why I=E2=80=99m not particularly surprised.

The main obstacle, and the main doubts, are not about what needs to be
done, but about whether it can be agreed upon.

It would be good to discuss the global implications for PHP if this
RFC is accepted. The global implications, or in other words a broader
roadmap of changes that become possible and logical if the RFC is
accepted.
I tried to look at such implications in my article about multithreading.

In an ideal world, I would like to be confident that everyone who will
vote on this RFC clearly understands the foundation of what PHP is
becoming:
* a language oriented toward single-threaded concurrent execution,
* with actors for multi-processor interaction.

That=E2=80=99s how I see the end goal. A high-level language, with a high
degree of abstraction over OS mechanisms. Without low-level elements.
Without access to fine-grained tuning. As safe as possible and as
simple as possible. A language with a built-in web server, socket
server, and other types of servers. With asynchronous extensions
enabled by default. The database connection pool should be available
out of the box and look like the usual, familiar PDO classes, without
significant changes.

Single-threaded coroutines are a proven compromise between high
complexity and ease of development.
Actors are a proven, maximally safe approach to writing parallel code.
None of these approaches is universal. On the contrary, they are all
oriented toward the web.

By voting for this RFC, you are voting specifically for a combination
of these two approaches, which has long existed in Node.js (except for
actors).
It would be good if this were absolutely clear to all participants in
the discussion.