P.s Oh right. I’d like to say a bit about how I feel, because there were assumptions here that I’m frustrated. Okay. I am not frustrated. I usually look at the current situation and understand how it works from the inside. Why? The thing is, rockets are exploding around me and so on. And then suddenly the question arises: someone in the world thinks differently. So what? Honestly? It doesn’t matter much. The world is inherently imperfect. Programming is not based on proofs. People constantly make various irrational decisions. It has always been that way and it always will be. And that is completely normal. You don’t get angry at rain, do you? Or snow? I also don’t feel anger toward natural things. Everyone will make their own choice. I’ve already made mine. In that sense, I’m comfortable. Those who will be voting have a much harder task.
ср, 21 янв. 2026 г., 23:41 Edmond Dantes <[email protected]>: > I never said that any projects were adapted for Swoole. Moreover, whether > they were adapted or not is a slightly different discussion. I was only > saying that the impact is well known. For example, it is well known how > coroutines affect Laravel. It is also well known that Laravel does not > support coroutines. > > Participation in the vote presupposes a minimal level of programming > literacy. This is not an insult, but an attempt to remind of that. It is > clear that it is impossible to be an expert in all areas, but it is also > impossible to make a decision without understanding. > > An RFC has two levels of complexity: the first and the second. The first > level is simple enough to be understandable by any programmer. Transparent > asynchrony and coroutines are not something that cannot be understood. > > We have come to live in a society where everyone is very eager to take > offense, instead of thinking about important things. I like to think about > something. > > > > ср, 21 янв. 2026 г., 23:24 Deleu <[email protected]>: > >> >> >> On Wed, Jan 21, 2026 at 5:42 PM Edmond Dantes <[email protected]> >> wrote: >> >>> If that were the case. But it isn’t. >>> >> >> Let's agree to disagree. >> >> >>> For example, the Swoole project has existed for more than 7 years. This >>> means that anyone here can check how coroutines actually affect their code. >>> >> >> And in those 7 years, it hasn't been adopted by 100% of PHP projects. In >> fact, I'd take a wild guess that its adoption is very likely below 20% of >> PHP projects out there. Just because it exists doesn't mean every PHP >> Software Engineer would benefit from it or that it's undeniably useful for >> any project or business. I first heard of Swoole in 2020. Ever since, I've >> had the desire to try it out, but never had a business case for it. If your >> RFC requires people to dive deep into knowing Swoole and understanding how >> it works and how it affects everyone's code, I would consider that to be >> one of the top reasons why the RFC hasn't gotten more traction. >> >> >>> There is already extensive experience with Laravel and other >>> applications. >>> All of this has existed for a long time. >>> >> >> Just because it has existed doesn't mean it is universally used. >> >> >>> If people cannot read the RFC and understand that these are >>> JavaScript-style coroutines, then why do they have votes? 🙂 That’s a >>> strange idea. >>> >> >> I see this statement as you going out of your way to offend the very >> people that have the power to vote on your RFC. They have a vote because >> they have contributed to the ecosystem of PHP enough to have a vote. An >> ecosystem that has existed without Async PHP for 3 decades. An ecosystem >> that requires thorough development, documentation, release, testing, bug >> fixing, security fixing. They have volunteered their time in proposing >> changes, getting those changes ironed out, implemented, adopted. They have >> improved the language. Just because they don't have your level of knowledge >> in asynchronous programming does not make their contribution any less >> meaningful or any less important. >> >> I can understand and sympathise that it must be very frustrating for you >> to put so much thought and care into this proposal and have no clear path >> as to how to make it land on PHP Core. But that is not an excuse to offend >> contributors of the project, especially given how narrow the subject matter >> is. There's definitely an appetite to have Async PHP and you're not going >> to get anybody on your side by implying that they are the problem in >> understanding your RFC. This is not a "one or another person" problem. >> There are plenty of extremely smart people participating in the development >> of PHP for years. How can the RFC be easy to digest so that they can >> participate more? >> >> >>> Yes, there are issues with understanding. However, a year has passed >>> since the publication. In one year, it should have been possible to clarify >>> any questions, if there were any. >>> >> >> The RFC is complex enough that giving it chunks of 30 minutes spread >> across many weeks is not enough to put forward every question that it >> warrants. 1 year or 10 years is not going to solve that. >> >> In other words, if PHP had never had such coroutines, that could be >>> understood. But the situation is exactly the opposite. >>> >>> As for trust, the problem is that people don’t want to waste their time. >>> They don’t want to play for a team with no chance of success. >>> >> >> I see no evidence of that. There is no one team vs another here. The >> change either lands or it doesn't. Being such a promising change to the PHP >> Ecosystem, it would be in any volunteer's interest to have been able to >> participate and shape the biggest change in the PHP Language in decades. >> But its not about "wasting time because its a loss cause". Its about not >> having volunteering time to grasp such a hard RFC. >> >> What can be done? A lot of things can be done. Last time there were >>> several proposals. But all of these proposals go beyond the scope of the >>> RFC. They require organizational changes. >>> >>> I can once again propose having two votes and an experimental mode. >>> The first vote would be on the core principles of the language’s >>> development for the next 5–10 years. >>> A vote on this RFC. >>> Or another option. There is more than one. For example, you could vote >>> in a first approximation, and then a year later in a second round. >>> >>> So... >>> >>> ср, 21 янв. 2026 г., 22:15 Deleu <[email protected]>: >>> >>>> >>>> >>>> On Wed, Jan 21, 2026 at 4:29 PM Edmond Dantes <[email protected]> >>>> wrote: >>>> >>>>> Regarding the group, I want to once again express an important point. >>>>> The main problem, the primary blocking issue, is that nobody believes >>>>> this RFC has any real chance. >>>>> >>>>> It’s like in the banking system: if you convince people that stocks >>>>> will fall, then even if it’s not true, the stocks will fall. >>>>> >>>>> At the same time, I agree with this assessment. >>>>> We are facing a paradox. >>>>> >>>>> To make changes to the language, you need to believe that these >>>>> changes can be accepted. Previously, there were doubts about whether >>>>> such changes could even be implemented. That problem has been solved. >>>>> What remains is the lack of trust in acceptance. >>>>> How can this be resolved? I think there are ways, and they are known. >>>>> They are just all outside the scope of the current RFC. >>>>> >>>>> ---- >>>>> Ed >>>>> >>>> >>>> I doubt the problem is about trust. You can trust that a company will >>>> not go bankrupt, you still need to understand how to operate and buy >>>> stocks. I think most readers are more likely to agree that you've put a >>>> tremendous amount of work forward and it's not that hard to trust you've >>>> done a great job so far. But if we don't know how things work, we can't >>>> help you make even better decisions nor can we make use of what you've >>>> built. >>>> >>>> I also don't think it's fair to expect from PHP's RFC process a >>>> position of: "trust me, this is the best, lets just merge it". Even if you >>>> were the best and smartest software engineer in the world, PHP is used by >>>> an immeasurable amount of people from all backgrounds, in many contexts and >>>> many approaches. Its not humanly possible for a single individual to know >>>> every possible way PHP is used and the RFC process is here for people from >>>> many backgrounds to provide their own perspective of things and voice how >>>> they think such a change will affect them or their project - be it a >>>> positive or a negative impact. >>>> >>>> Right now, I think the "fairest" assumption is that we don't have many >>>> such voices because nobody can read, understand, interpret and predict how >>>> this RFC would play out in their projects and their work. It's far too big >>>> of a change with too many concepts, mainly foreign to many people working >>>> with PHP and there isn't a clear path of contributing to the discussion. >>>> >>>> How do we solve that? >>>> >>>> -- >>>> Marco Deleu >>>> >>> >> >> -- >> Marco Deleu >> >
