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]
