Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129355
Precedence: list
MIME-Version: 1.0
Date: Fri, 21 Nov 2025 09:47:28 +0200
Message-ID: <CAMW7n8DQSVyR0ioQZC7QQj-MpykY8L=m_T-k9rzifny21N31GA@mail.gmail.com>
Subject: [PHP-DEV] True Async: Some words
To: 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)

Hello all.

If I had known that the vote would create such a hot day, I would have
started it even earlier :)
I will try to express in this message the same things I wrote in
private messages regarding how Async should be implemented in PHP.

How programming languages adopt such complex changes:

1. A working group is created to discuss a PreRFC.
2. A PreRFC is written, defining the project boundaries and
establishing its key principles.
3. The group refines the PreRFC until it is ready for a vote.
4. The community votes on the PreRFC, confirming that it agrees with
the basic principles and will support them in a future RFC vote.
5. An experimental phase is announced. From this moment, a special
build of the language is created, allowing anyone to try the new
features.
6. The working group continues integrating the new feature into major
frameworks and other important libraries.
7. After analyzing bugs and real-world issues discovered during
experimentation, the RFC is adjusted if necessary.
8. The RFC is voted on as final. The experimental phase ends, and the
changes become part of the permanent language release.

I have already proposed this to the PHP Foundation, and I am doing so
again. Why? Because I am 100% certain that the only way to implement
async in the language is by doing it together.
This is not just a nice phrase. It is the real situation.
PHP is a language with relatively limited funding and very few
resources. If these resources are scattered, there will be no result.

TrueAsync has two major goals that represent its most important values:

1. Creating a coherent infrastructure with a complete set of tools for
asynchronous programming. Yes, coroutines will run in a single thread.
For now, this is the most realistic goal.
2. Adapting the existing I/O functions for coroutines instead of
creating new ones.
(I can explain the second point with technical reasons if needed.)

If the PHP Foundation, PHP Core, AMPHP, ReactPHP, Swoole, Swow, and
framework representatives understand the value of these points and why
they are needed, and if there is a chance that we can reach this
vision, then the TrueAsync project has a chance to continue.

I do not believe that PHP can become better by splitting it into
subsystems. I do not believe that this would be successful.
If this happens, most likely everyone will lose.

This is not a question of whether Edmond is right or wrong. It does
not matter. This is a question of survival. I am not joking. And it is
not funny.
If anyone has illusions about a backend language without async
support, they will shatter sooner or later. You just have to wait.
But it seems to me that after these 3-4 years it is already clear what
is happening.
Do you need another 4 years? You do not have them.

So=E2=80=A6 as the great evolution teaches us: adapt.
If resources are limited, join forces.
These are simple laws of survival.

If principles like =E2=80=9CIt was not invented here=E2=80=9D or =E2=80=9Ct=
his cannot go into
our core=E2=80=9D win over economic arguments, then the market will be take=
n
by those who adapt better.

Maybe discuss it publicly here.

P.S.
Actually, =E2=80=9CTrueAsync=E2=80=9D doesn=E2=80=99t sound dramatic enough=
.
The real name should be: **Blaaaaaaazing** TrueAsync :)

---
Edmond