Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129321
Message-ID: <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
Date: Thu, 20 Nov 2025 11:18:30 +0100
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>
Content-Language: en-US
In-Reply-To: <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: daniil.gentili@gmail.com (Daniil Gentili)

Hi,

>> Hello Bart.
>> I am ready to agree with every word.
>>
>> Participation from a working group, framework representatives, and the
>> ability to adapt libraries in advance would remove the concerns that
>> are currently causing fear. This is probably the only effective
>> process for developing and introducing such a feature.
>
> Then two days later, you decided that no more discussion was 
> necessary, and opened a vote.
>
> This feels like a complete contradiction.
>
> Let's find a way to get that working group set up, and get people from 
> other projects involved.
>

My key takeaway from Bart's message is:

 > Moreover, even though there are quite a few people in the community 
who have the knowledge required because they either develop or work with 
aforementioned libraries or extensions, (almost) none of them seem to be 
involved in discussing this RFC.
 > For an RFC that can drastically change the way we develop 
applications I would expect more experts on this matter to be involved. 
Ideally, PHP core developers, library developers & maintainers, IDE 
developers, ..., would develop software using this branch to at least 
get some feel for the paradigm and this RFC in general.

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, and thus haven't:

- Experienced the pain of writing async with colored functions
- Experienced the footguns of structured concurrency
- And on the other hand, haven't experienced the pleasure and simplicity 
of safely writing async code in languages like Go, or in PHP using AMPHP 
(which use uncolored and unstructured concurrency, the kind proposed and 
championed by edmond)

While a working group *can* steer the conversation away from 
theoretically correct but practically unusable approaches, that can 
happen only if

- The correct people (i.e. async library maintainers, or people that 
write async logic every day in multiple languages like myself) are present
- They are given more weight than the average PHP developer who hasn't 
used async much if at all, and can only make theoretical proposals not 
based on practice and experience

I'm afraid that given the current state of the PHP community, which is 
largely new to async, the quality of the conversation in a working group 
would not be much higher than the one I'm seeing in this RFC, and would 
just protract even longer the agony of design by committee, where in 
reality what's needed is a single, clear and correct vision (which 
Edmond has), without influences from unexperienced people making 
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.