This thread is a clear, explicit and direct representation that there are people following all the hard work that you’ve put into this RFC. I dare say that nobody doubts your intentions, effort and initiative to tackle such a complex and hard task.
The next step is to recognize that anybody participating in an RFC discussion is a person taking time out of their lives, their family, their work, their hobbies and volunteering their time similar to you. Everyone has PHP best interest at heart even if what we think is best for PHP differs. On Sun, 16 Nov 2025 at 03:56 Edmond Dantes <[email protected]> wrote: > Hello > > > Maybe that’s inherent to a subject matter that indeed could be the > biggest change to PHP since 7, > > but given RFC voting history, all signs point to a rejection vote. > > I think so too. > > > I don’t know how much has been discussed off list and/or how many voters > are involved off list. > > There were almost no discussions apart from the one on INTERNALS. I > mean, there were no discussions that I’m aware of. > > I don’t know what to do about a situation where PHP developers are > surprised to learn that their language has supported transparent > asynchrony as a core paradigm for several years already. I suppose you’re referring to Swoole, AMPHP, ReactPHP, etc. While there’s no denying they’re an important part of the ecosystem and living proof there’s room for asynchronous PHP, your positioning here seems to assume that everybody participating in your RFC should know, understand and use one of these projects and have that baseline knowledge. From my personal experience, context and little bubble, I would guess that less than 10% of PHP engineers worldwide has any firsthand experience with any of these tools combined. Your RFC can bridge that gap, but to do so you need to be able to address why the other 90% hasn’t used any of these existing approaches. Your target audience is exactly the opposite of what you expect. > And instead of discussing the important details of the RFC, all the > effort goes into “basic questions” that aren’t worth discussing at > all. This is perhaps the most likely reason for the RFC to fail a vote. Let’s break down voting in an abstract format. Some common reasons voters may choose to vote NO are: - they don’t like the change and don’t want it on PHP - they disagree with the approach - the change increases PHP maintenance burden for a subjective benefit - the RFC is unclear There’s not much you can do about 1. And for every NO you get, you need 2 YES to overcome it. My personal guess is that 4 would drive a lot of NO and the reason is a combination of factors. It’s a very complex and dense RFC and not every voter will have any experience with the existing async tools provided by the community. When trying to take time out of their personal lives to go through such a complex and extensive RFC, basic questions will arise. They will attempt to address it before going deeper and deeper and will be met with a dismissive response from the author “because this is too basic and we shouldn’t focus on it”. They will make the easy choice to not continue to volunteer their time into something so hard to wrap your head around since it’s too challenging to even get past the basics. A negative result is not really a surprise at this point. It would be wonderful if there were a dedicated person whom everyone > would listen to carefully and who could explain the basic questions > privately. Most likely, this approach would solve many problems. > > --- > Best Regards, Ed Short of forking PHP, that seems like wishful thinking. PHP is driven by committee and there doesn’t seem to be any way around that. But there are approaches you can try. One of them is pairing it up with someone better at docs, communication, etc. Take a look at Larry’s RFCs. Majority of it he doesn’t write any C code, but he makes up for it 10 times by producing clearly readable, understandable and decision points communicated. Voters may still disagree at the end, but it always feels like they understand what they’re voting on/for. I don’t know if you’re good with a camera, but going in a podcast with someone like Brandt, Nuno Maduro or any other PHP podcast that tries to breakdown internals for easy consumption could also help your cause. Ultimately, I think your vast expertise on the matter is both a blessing and a curse. A blessing because without it maybe the RFC would have never even existed - at least no other RFC on the matter has reached so far. A curse because nobody else seems to be able to understand what you’re saying, what you’re doing and what PHP will be like if your RFC is approved. As someone writing PHP for 15 years, I’m scared of bringing any async community tools to any project I work because I don’t know what would break. Your RFC states that you want all my code to keep working which is great, but the moment I make use of something async it could inadvertently affect something and I don’t know what/why/how. I’m dumb and don’t know how async works and I don’t want PHP to allow me to shoot myself in the head like that. Is there anything you can do about it? I wish you all the best luck on the RFC and your next steps. I thank you for all your time so far and I’m eager to see what come out of it. >
