Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129382
Precedence: list
MIME-Version: 1.0
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>
 <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk> <CAMW7n8CLZ7yFhUhh89wx7L+YwQ25LA7HZoGWUFB3R76KgXko2w@mail.gmail.com>
 <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com>
 <CAMW7n8D5B=XVX_Jes+LV=2fPwjQr_RBVphPi_Cxm8-_Rwpdo_Q@mail.gmail.com>
 <CADK1yX+jGtqQVYFTo5YmkenPrNcXz7Dd7RCUKWGrq+50pnKOnw@mail.gmail.com>
 <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
 <CADK1yXKgkuKmOMB7KA9GNQMtpNw7ZgWcPEPE_Uhr_+8eReDCEA@mail.gmail.com>
 <CAMW7n8D+RGAFDY3oGnzaAabrhW9TOMeBgtvx4zCy3AoBUb5szA@mail.gmail.com>
 <CAEKnhAFsXpfZy8FQyA4Z9bNyNa26rCCn5GO=oQ274e1K2+GkAw@mail.gmail.com>
 <E4EE97C5-76EB-4C65-A3BE-7FFE27DD1500@rwec.co.uk> <383528143.397454.1763760932585@email.ionos.de>
In-Reply-To: <383528143.397454.1763760932585@email.ionos.de>
Date: Sat, 22 Nov 2025 06:17:56 +0200
Message-ID: <CAMW7n8BjVM7SdM8Jn3dOmrXgngxycerZr9Cm4jeACnXaETQCWQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Thomas Bley <mails@thomasbley.de>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello

> from userland perspective I would prefer explicit declaration on each usa=
ge of async over declare(), hooks and INI. This would make reviews, static =
code analysis, etc. easier.
> RFCs can be written in small parts for each new function, e.g.

This solution has the following consequences.

We have a REST API project that is 10 years old. Recently we learned
that PHP 9 has been released, and we can improve performance. To do
this, we need to:
1. Migrate to another web server.
2. Wrap the request-handling code in a coroutine.

However, it turns out this doesn=E2=80=99t work. If the code inside the
coroutine doesn=E2=80=99t yield control, then there is no improvement at al=
l.
And we=E2=80=99re like=E2=80=A6 this technology is useless.

And then one of the developers says: =E2=80=9CGuys, we just need to rename =
all
functions to _async and it will work.=E2=80=9D
(And he=E2=80=99s this young optimistic perfectionist programmer who says:
*=E2=80=9CThen the code will be beautiful, amazing, and blaaaaaazing!=E2=80=
=9D*)

Everyone happily writes a script to rename 30-50,000 lines of a
many-years-old project. New bugs appear. But we fix them, hoping for a
better future.
And then it turns out that after renaming the functions nothing works,
because shared memory has to be removed.

In other words, the team spent time on refactoring, and in the end
they still had to do the refactoring that was unavoidable.

What benefits did the developers gain?
1. Did the code become clearer? Yes, the code became a bit clearer.
It=E2=80=99s visible that the functions will yield control.
2. Did the number of bugs decrease?
3. Did the amount of code changes become smaller?
4. Did API segmentation appear?

People won=E2=80=99t rewrite code unless the business is at risk. And even
then, very often no one does anything. Therefore, the **more**
complicated the transition to asynchrony is, the **less likely** it is
to ever happen.
There is a chance that asynchrony could give the language a push
toward greater memory safety and make it more functional in style.
Because features in programming evolve according to the law of
accessibility. The more accessible a feature is, the more likely it is
to be used, and the more widespread it becomes. Go made parallel
programming more common because it made it simpler.

---
Ed