Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129829 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id BABED1A00BC for ; Wed, 21 Jan 2026 21:42:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769031734; bh=gtDHbyO7BSV22oSr+jP+VyVHvxtXmLPUhC5A9PkXl4w=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FWQleqn7BdHKItQjYLexeHWZzUzWVwQDELuEiK027jNbedpBSAulgT9TxiC1I71pw NzPyIUNFAFSwSvs9Zaw/zzxAPVqSYtJjwKv6zOk1T037EGLL5NrD0pRVcWIM3idakk OPYbwAu20c6ohR0Phh0sLpVn2biHqpeOY+p6F0zfG0XTX5OC3zpMoRX6+O/EYvo2Xh H60p/nBL5FcHlS6GjU7kPXMiBsoq6lLfNeEry9BrqRPW/m+Kw8Pazr/l2o+1Cr78H+ qT9m6dgxciLoNbfUAu0lr1vnPoXSZYdxA2eCEh/BUZ6VzmgIx6Z2u5tB+4v2Xd15eK XnBN+kwQU0Aiw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D9D3E18003B for ; Wed, 21 Jan 2026 21:42:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 21 Jan 2026 21:42:12 +0000 (UTC) Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-56365984503so205206e0c.0 for ; Wed, 21 Jan 2026 13:42:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769031727; cv=none; d=google.com; s=arc-20240605; b=Yct6mTIucVd/vsSUZ7s6FriTWOYkIYLsZLXhbGmCq2So9lUYTG3kMTQ134yhAWc/ok hQYef7+wxXRHsA6RDSaXlecXsFeo6LwGr4hRgQaqUOVCSxOReYh7ulX3ZMsLP/fuU6i/ rKOrnTJzvg6CQGj2OsH3BAcaKnfaVMbohQumfFA9tbzMjDcfI1ZhCsjLmhLTA/FEhliE C+TIduQy7zrtHUF1RnMPlhnEArwPQDP85mv7UvEYgnLMg7610+UnlW5t+ZSv1T/pUEsC lCoHZTZcOAcYx5AaCyDxXydMgMMfHi/KnUnafUCgliNMArObMHEHLDAQpcj784XlfiaV xzMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gtDHbyO7BSV22oSr+jP+VyVHvxtXmLPUhC5A9PkXl4w=; fh=J5MnZTiYttcUm8J4LNyR/rFPhZBFL0iiOf3qSYgVBBE=; b=Ss4k9LSpI/VlqYjDfMfnSuurnViBEujFdEU7wiNKaRrEbdoKMS6qLuW6rGjkVtGG6M y1IvvSGrMxBSlk0ibNNrwshziGd2whiNj4KY2Wp8ZqtyAJF2ekXHZr2z0Ebz42fQ/qlx rbDX0oIHAtpthZpGsRJjozo467m1daF/wZH/KWKEd3+OY0BkVvSNr/3D81DOGqtSirOb OUqLACWpjYatJffTslbxa5LvO1XUuuCyYgl9N18fQxiKMKO5ATiABLY9/rQ+GQ64EkjY Y8um+yc3gV96v139N+ie+qSOJQTkm7Wyq6sH/oqhhggTHhortVB95xCnhkEcqKoO1uZY ftsg==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769031727; x=1769636527; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gtDHbyO7BSV22oSr+jP+VyVHvxtXmLPUhC5A9PkXl4w=; b=kz27pFEr+619PKtipGA7IeYOHHd6izFLk5ENkBBGdOWCRlvjHPel4x5+p6VeiuKe2y F7kyBeiqphooxYZbangMQp9Xs3tWoV4KzbFYsbUlOaMbgMDL2f7rfeEqS9Siv9IXrzqv TOA9BZIT5AZ5YOkO2M++8UbKdQPI2wDpD3Ae0llrXu8cfWlgYOYat6opcAENxDspuHGA yvNJOaqLxrz1ofzl3g0xF0nKwba1tV3H9t79vBEXtFyg4DiEHvTKM+VYsHCi6gEPmqMX zDTAUY9KIeclcH4EUBvVxZyvCjxMROAC/wH4HpN73oSnu+zzXjFCY9eJP1eqKiX9BAOy sGzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769031727; x=1769636527; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gtDHbyO7BSV22oSr+jP+VyVHvxtXmLPUhC5A9PkXl4w=; b=oV453kLsQfRxVE+IcgIAeuNndO4DYOWGkS2SUHjSNOgmktTQDOXrTNoengwfQ8AjPC RdoFnmbXC+0LInCJAsjIbgLx6It/Nma3vlpgl0x30N6OxxkPfG+MERQI2VBTsZs0B27q ZaLbXBW+TvMCLi7IYasLT//WbZEdYlLrbt2LbN6PNZQSeBB2yu3QacEfVzCiIL2yTEm5 2pkeMfjZZyjh30Va11yve/N16Uhma07nRoUrRgCAoY/DUHn/WDm/4oSkF72GFlk5K5+x GjUni5kxCbev8lLfARh2fp267b9B+WbYZkXPnyC4B9rT8reeGU1iwoVvwA7sbfsVzdu3 jTyw== X-Gm-Message-State: AOJu0YxfzcVviRHVeFKpnKb5pVLIXpdzkV0zZmq9qpBs41AJhZhcxpnK C17f64vMbFoDkNbS0zIyjA2Dadqe8xNd5tYjaESCDeIiJQVDuBrN38ea12pgQYBbxBi9bSbwbh7 /cWyeszU0uzY41BrwMuR16tIpSg35cg8= X-Gm-Gg: AZuq6aKLN5zSXsotBMojnLPDFDPL+B/cuG0QlW0A4XF+WduKFokSDoYS7nUqLy5LLVL K/lINZem69/WFCj9GKpCzCqqbR71E7RQztfTi/TX8j4LiPwXjJChVHGmLruArgsjoXZwP/1x2pM BI1H0qC/2qVPHK0RlOsTPj6SLUvTTssGczc+r6tW/atjU53nLrC25p98PdWKQRA+7OyQXzck4xx UqTGYw6dET2v71dVvq2UVjmupWv+eZayU/FFbRvgo9nYVYFOyp9nU5SGYjsGUNKJ8dF2bxKxKuL OrB3uJ/qlyvo7CwTLBiMiyk8nkw= X-Received: by 2002:a05:6102:441a:b0:5db:d60a:6b2f with SMTP id ada2fe7eead31-5f1a6cd095fmr6061292137.0.1769031725272; Wed, 21 Jan 2026 13:42:05 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <79CDB2CC-E397-436E-B5A2-10DA1E451A97@rwec.co.uk> In-Reply-To: Date: Wed, 21 Jan 2026 23:41:54 +0200 X-Gm-Features: AZwV_QhkPTB7v-9k1rDxss3uO9bhzgxH1Ysbt0g7z9s7LEva8iLpHpUnbEYUg2I Message-ID: Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7 To: Deleu Cc: php internals Content-Type: multipart/alternative; boundary="00000000000094d0a40648eccb6c" From: edmond.ht@gmail.com (Edmond Dantes) --00000000000094d0a40648eccb6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:24 Deleu : > > > On Wed, Jan 21, 2026 at 5:42=E2=80=AFPM Edmond Dantes wrote: > >> If that were the case. But it isn=E2=80=99t. >> > > 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 co= de. >> > > 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 fo= r > any project or business. I first heard of Swoole in 2020. Ever since, I'v= e > had the desire to try it out, but never had a business case for it. If yo= ur > RFC requires people to dive deep into knowing Swoole and understanding ho= w > 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 application= s. >> 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? =F0=9F=99=82 T= hat=E2=80=99s 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 hav= e > improved the language. Just because they don't have your level of knowled= ge > 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 offen= d > contributors of the project, especially given how narrow the subject matt= er > 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 developme= nt > 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 clar= ify >> 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=E2=80=99t want to waste the= ir time. >> They don=E2=80=99t 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 P= HP > 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=E2=80=99s >> development for the next 5=E2=80=9310 years. >> A vote on this RFC. >> Or another option. There is more than one. For example, you could vote i= n >> a first approximation, and then a year later in a second round. >> >> So... >> >> =D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu <= deleugyn@gmail.com>: >> >>> >>> >>> On Wed, Jan 21, 2026 at 4:29=E2=80=AFPM Edmond Dantes >>> 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=E2=80=99s like in the banking system: if you convince people that s= tocks >>>> will fall, then even if it=E2=80=99s 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'v= e >>> 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 positio= n >>> 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 an= d >>> many approaches. Its not humanly possible for a single individual to kn= ow >>> every possible way PHP is used and the RFC process is here for people f= rom >>> many backgrounds to provide their own perspective of things and voice h= ow >>> 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 worki= ng >>> with PHP and there isn't a clear path of contributing to the discussion= . >>> >>> How do we solve that? >>> >>> -- >>> Marco Deleu >>> >> > > -- > Marco Deleu > --00000000000094d0a40648eccb6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I never said that any projects were ada= pted for Swoole. Moreover, whether they were adapted or not is a slightly d= ifferent discussion. I was only saying that the impact is well known. For e= xample, it is well known how coroutines affect Laravel. It is also well kno= wn that Laravel does not support coroutines.

Participation in the vote presupposes a minimal level of pro= gramming 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.=C2=A0Transparent asynchrony and coroutines are not some= thing 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.=C2=A0

<= br>

=D1=81=D1=80, 21 =D1=8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 23:24 D= eleu <deleugyn@gmail.com>:


On Wed, Jan 21, 2026 at 5:42=E2=80= =AFPM Edmond Dantes <edmond.ht@gmail.com> wrote:
<= /div>
If that were the case. But it isn=E2=80=99t.

Let's agree to disagree.
=C2=A0=
<= div dir=3D"auto">
For example, the Swoole project has exis= ted for more than 7 years. This means that anyone here can check how corout= ines actually affect their code.

And in those 7 years, it hasn't been adopted by 100% of PHP pro= jects. 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 mea= n every PHP Software Engineer would benefit from it or that it's undeni= ably=C2=A0useful for any project or business. I first heard of Swoole in 20= 20. Ever since, I've had the desire to try it out, but never had a busi= ness case for it. If your RFC requires people to dive deep into knowing Swo= ole 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 g= otten more traction.
=C2=A0
The= re 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.
=C2=A0
If people cannot read the RFC and understand that these are JavaScrip= t-style coroutines, then why do they have votes? =F0=9F=99=82 That=E2=80=99= s a strange idea.

I see t= his statement as you going out of your way to offend the very people that h= ave the power to vote on your RFC. They have a vote because they have contr= ibuted 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 thorou= gh development, documentation, release, testing, bug fixing, security fixin= g. They have volunteered their time in proposing changes, getting those cha= nges ironed out, implemented, adopted. They have improved the language. Jus= t because they don't have your level of knowledge in asynchronous progr= amming does not make their contribution any less meaningful or any less imp= ortant.

I can understand and sympathise that it mu= st be very frustrating for you to put so much thought and care into this pr= oposal and have no clear path as to how to make it land on PHP Core. But th= at is not an excuse to offend contributors of the project, especially given= how narrow the subject matter is. There's definitely an appetite to ha= ve Async PHP and you're not going to get anybody on your side by implyi= ng that they are the problem in understanding your RFC. This is not a "= ;one or another person" problem. There are plenty of extremely smart p= eople participating in the development of PHP for years. How can the RFC be= easy to digest so that they can participate more?
=C2=A0
Yes, there are issues with understanding. Howev= er, a year has passed since the publication. In one year, it should have be= en possible to clarify any questions, if there were any.
<= /blockquote>

The RFC is complex enough that giving it ch= unks of 30 minutes spread across many weeks is not enough to put forward ev= ery question that it warrants. 1 year or 10 years is not going to solve tha= t.=C2=A0

In other words, i= f PHP had never had such coroutines, that could be understood. But the situ= ation is exactly the opposite.

As for trust, the problem is that people don=E2=80=99t want to waste= their time. They don=E2=80=99t want to play for a team with no chance of s= uccess.

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 woul= d be in any volunteer's interest to have been able to participate and s= hape the biggest change in the PHP Language in decades. But its not about &= quot;wasting time because its a loss cause". Its about not having volu= nteering time to grasp such a hard RFC.

What can be done? A lot of things can be done. Last time ther= e were several proposals. But all of these proposals go beyond the scope of= the RFC. They require organizational changes.

<= /div>
I can once again propose having two votes and an exp= erimental mode.
The first vote would be on the core = principles of the language=E2=80=99s development for the next 5=E2=80=9310 = years.
A vote on this RFC.
Or= another option. There is more than one. For example, you could vote in a f= irst approximation, and then a year later in a second round.

So...=C2=A0

=D1=81=D1=80, 21 =D1= =8F=D0=BD=D0=B2. 2026=E2=80=AF=D0=B3., 22:15 Deleu <deleugyn@gmail.com>:


On Wed, Jan 21, 2026 at= 4:29=E2=80=AFPM Edmond Dantes <edmond= .ht@gmail.com> 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=E2=80=99s like in the banking system: if you convince people that stocks=
will fall, then even if it=E2=80=99s 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 forwar= d and it's=C2=A0not that hard to trust you've done a great job so f= ar. But if we don't know how things work, we can't help you make ev= en 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 m= erge 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 backgro= unds, 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 proces= s 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 pr= edict 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 pe= ople working with PHP and there isn't a clear path of contributing to t= he discussion.

How do we solve that?
--
Mar= co Deleu


--
Marco Deleu
--00000000000094d0a40648eccb6c--