Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129351
Feedback-ID: id5114917:Fastmail
Message-ID: <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk>
Date: Thu, 20 Nov 2025 22:18:40 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: internals@lists.php.net
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>
Content-Language: en-GB
In-Reply-To: <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 20/11/2025 10:18, Daniil Gentili wrote:
> I absolutely agree with this take, however, so far, the discussion 
> around this RFC has been, in my opinion, mostly bikeshedding, with 
> theoretical correctness proposals that are an absolute nightmare in 
> practice (like structured concurrency), proposed by people that 
> admittedly have never written extensive amounts of async code in 
> languages using multiple paradigms


That is exactly why I think some other process is needed, and why an RFC 
vote right now doesn't tell us anything useful.

I really want this feature. But I really want us to get it right.

As someone who is completely new to the topic, the things that will make 
me vote "Yes" on an async proposal, are:


1) Confidence that experts have reviewed the design, and ironed out 
crucial details.


 From what I've seen, Edmond has done an extremely thorough job. Once 
again, thank you, I tip my hat to your effort and dedication. But I'm 
not qualified to judge the result, and I want to see opinions from 
people who are.

It may be that after discussing it with a bunch of other experts, 
exactly the same technical design would come out; I just want a bit of 
reassurance that the right discussions have happened.

Has there been an attempt to invite specific people into a discussion, 
e.g. people who've worked on ReactPHP, Swoole, etc?


2) A cast-iron promise that existing code would run unchanged; or a 
clear explanation of what modifications it would need.


The "Goals" section says code will not need changes "or changes should 
be minimal"; and will run without modification "provided that..." Those 
caveats worry me.

I work on a code base with a million lines of PHP code developed in half 
a dozen frameworks over twenty years, maintained by a small team. When I 
hear "it took us 2-3 days to update a library", I don't hear a small 
number; I multiply it in my head, and wonder how I would justify weeks 
of development and testing. Right now, I don't even understand what we 
would be spending those weeks doing.

If it really is a case of "it will be fine unless you're doing some 
weird tricks to force PHP to do things it doesn't normally do", then great!

If it ends up as "set this global setting, and you won't get the 
benefit, but your legacy code will run fine", I can live with that.

If the only advice is "your code will be fine as long it's already 
well-architected and completely covered by automated testing", it's no 
use to me - that's just not the reality I live in.

I sincerely hope that this is solvable.


3) A set of "idiot-proof" high-level features that a non-expert PHP 
developer can use without understanding the full implementation.


The current RFC is a lot more focused than previous versions, and that 
is great; but it still gets very quickly into the mechanics and 
edge-cases that require expertise to use.

What I think is missing is the pitch to users. Something that we can put 
on the php.net homepage, and say "look how easy concurrency is in PHP 9!"

To paraphrase the Perl slogan, I want the language to make the common 
things easy, and the complex things possible. I want a "pit of 
success", where the easiest thing to write is also the most likely to be 
safe and useful.

I think that mostly just means defining some syntax sugar on top of some 
of the functions and objects. Something that we can say is PHP's 
equivalent of async/await, or goroutines and channels.



But ... I realise this can't all fit into one RFC without discussion 
going on forever.

Which is why we need to find some new process to make it possible.



On 20/11/2025 15:39, Jakub Zelenka wrote:

> I think the way forward for PHP is to do what we have been doing and 
> it is to provide the building blocks for user space to enable async 
> there because that's something that can be reasonably introduced using 
> the RFC through smaller chunks.

I think it would be a shame to throw away the progress that's been made.


I wonder if a way forward could be something like this:

1) Agree a Project Charter, some Goals and Non-Goals. Hold a vote on 
this, to agree that we're going ahead with the project

2) Set up some kind of project tracker, where we can list open questions 
and design tasks; maybe a separate mailing list / forum / chatroom for 
those involved in the details

3) Start with Edmond's amazing work, and iteratively work on those 
individual questions

4) Keep bikeshedding questions (e.g. "what is the best name for this 
class, and should it extend Error or Exception?") separate from 
architecture questions (e.g. "is this class necessary, or should it be 
hidden from the user?")

5) Converge on a solution where we've already agreed everything in 
bite-sized pieces

6) Release PHP 9.0 and celebrate


All of that requires that enough people who actually understand the 
problem space deeply are willing to be involved and collaborate. I 
really hope that's the case, but I am not in a position to volunteer myself.


-- 
Rowan Tommins
[IMSoP]