Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129828 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 48ACD1A00BC for ; Wed, 21 Jan 2026 21:24:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769030682; bh=p2pvG2dngN+R2wVgPTcFRKLqPCmxwOh1wpyOIaSVlOg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=JHRtry59V7SEGfWVX5VcQRvXm63WKbgqRJEj7WiUJEOSQXsG6xx4ZQtX/kBb+LZBY p8nD8SwKUXgv1iUyOQqtiCdzw7EgzEvexsMxxUs6BrOa8CvnoiUTDYOLLEMfhvsDkL XpLFCe8jOn6Wt/v+ugHCqdhhzeStV4sqyB7pX4xq5Z0gcty5Kr0Rgqyq7ZMpj2Vs35 agR4bxFYlCX7oLzc1jNoP9itcCZpa5YtekCzijAE/fkpqV64g02sTFimSwwEGMaAIU iGk3VHy/LOvTsqeIMyf8+YDsr8zS058aT7QIP6+2eIw25Rg5TOis3rRc+Yhv/tGAvh Fg89fvLSoXbTQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 68B2F180086 for ; Wed, 21 Jan 2026 21:24:41 +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-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (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:24:40 +0000 (UTC) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-78f9b964c3eso540847b3.1 for ; Wed, 21 Jan 2026 13:24:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769030675; cv=none; d=google.com; s=arc-20240605; b=YtIQeszO1Mt8623CX999tTLnOsDDj75C0xOcOfsWeqyDadlp5p+jnSdjqyJw5TD9V+ UEaJ4p35YyyhEB2tgvLjS0U+qGAuwfIuj/x+MFP+Mysok6lqBg3i8BmHjO6ks1g2u15n nVFAlbyEU/xq7Qg4fT+HR5hc0UO2ajBd2FngtqS0rz4uV+UzzJn2KAKhDwYjHV9XwSpq FWKbtn83Y+WEh2D/OAzb44VME2o5tkcTqZDYi1uvjHr6XyX3VHdMW/5tncqMKh2xG+qP 7tKb/+DVrzw/aBDQjTxHHDuSSFqeurJVjk/9QEssZ3FFuz2Eu+UZAADR7kiBImVvBOhB qm3A== 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=p2pvG2dngN+R2wVgPTcFRKLqPCmxwOh1wpyOIaSVlOg=; fh=+kHlIL0wskoGokJK9uOS1+eswHumjG9dfmq0j5jXo3s=; b=W9tEtY12BpVp4GykVn5NPu9O2upmAZ/sCeYPt7s2rA/3ZNyR5S9aDXWpAtYExUgyHn ljcZYXmBo4I+C93+r2BIyxlF2hC+//KzHfCZqDW/fouR8+Lpv38PaZ+bTal3EBmGR3WE hjCXrIpLs8sGf91Q8PcTaiYA/fTYQShw6wtW8BwAwek77uk3GX0toRf7QFhXi1qLawKM rvipBjVQX1HyIJD5EVT/T3w7LW/R/RWiPIIpnNZyYKRi2MUlGn0+J3Hk4pHhRfbPZUZV e8hEuaBPKcJJtY9xucHciOBzYgzqZdOSQ60po1i0ng6IqoilgSSn0ovRqQtTR+PRV9J/ 41tw==; 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=1769030675; x=1769635475; 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=p2pvG2dngN+R2wVgPTcFRKLqPCmxwOh1wpyOIaSVlOg=; b=mgIenrFyAO87UvcshkxssskcwbFJnAJPmXLVLvMCle+iJHCDlNHm2Z+nlyluwcTRxt R/1M7kG6m8bsB0UxG1yL0+/CnOA8dT3oGzGGgg3utfox246J7Evmu8T3nHLh/TSOJu/k YXGIVt/C9XBWQXqFPRY6l3DwEotefQ/g8bD2gUCNDB+Os/87EiSnlVL1pziS2B0mqQsI KD5J4RdgaBGSYXwMg616R6gKnJGncuPek8NvT3+k/oKSyBhmiB8W9vb5mGBItJOMseXz W96PLmoSBji2rI3V8PsBmqsfI612seHx1UmCY5GvELYpeUg8WkeswPN6muvoBL10UbSD VRwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769030675; x=1769635475; 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=p2pvG2dngN+R2wVgPTcFRKLqPCmxwOh1wpyOIaSVlOg=; b=nfGHywspqjRiyoLCmMtP4uywoImZ7CpTo0TMwwc2J3ka9xt/S97RiYhRjwr5bRn5Oh m2kUbw98sFPYVcjO9fYUFSu2qdPlGekIy9mQP3tNFCKxJmuVSpWJANpJreju6RuK1DnY o70gWW3hNT3+RWJw52TqrVtVNLn8aMxejcCbPCi8WdB+n6iCLNdpQ6xLAxGjD/oZnqOg YUPpQ/8m+wEFE4A5fQRRWuBl6G676WoeOQNbq+yybW60F9z5qdUq3MYxdZEQsbzd1gBW noHjP4NavVy1p5i2vqMVbyc1Y7lUBmALh6LFGBNaVsFxngJfj/hc41GyV8UEubbe0yRD eEUw== X-Gm-Message-State: AOJu0YzRpkYXwAQdLBQplXaSbDVyVALuouMnbkmfxDR32/O44e6b52cH P+mCTU4LigifuwKZ9Nk2Te91YBfEgANbPly2dwMnInNDx40/OGK5fC6YxwJ0yuE3UOhgpyMDrnG CEodrJCvRUy9hM4Ciu66V6drj0u4Fe0q2t8NU X-Gm-Gg: AZuq6aIpMijhzHggK9Y6xIYg1KM2wiCMG+G6iEfca8bB6nOseRHK3k32TcdmYdkNj9L fh7Dq4TqhXoHZd4SJPpbzGl4Lt9laHoUfmU13irieE85EQGX2Ch03b8Ezxwu0niXtkbC8a0I2BP bHgVlR2KMrCpTzgYEUl1CikKTJKnFeC/htBgS8xI+ic+JF7LTUQ73bT20gozffEOpnmt3f/1kJ8 Rsh3ijoFVdl0lhTGJxsQB0GMjImFtVqiAjmR9s8v4PfOZ9zydiJfJ2xNxGi9PPzbr74Xm9h8qkz OUX/e2jJHUv2NjpYhHuE+jCdJHc= X-Received: by 2002:a05:690c:a711:b0:794:6b4:4664 with SMTP id 00721157ae682-79406b44cbfmr44073587b3.9.1769030675017; Wed, 21 Jan 2026 13:24:35 -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 18:23:59 -0300 X-Gm-Features: AZwV_QjjUxWYGziOsoqnKPnjDzad7Pjsbgo4OS4iW4sFU0_4sYXDO8iOdykq4S4 Message-ID: Subject: Re: [PHP-DEV] Re: [RFC] True Async RFC 1.7 To: Edmond Dantes Cc: php internals Content-Type: multipart/alternative; boundary="000000000000fb366f0648ec8c14" From: deleugyn@gmail.com (Deleu) --000000000000fb366f0648ec8c14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 cod= e. > 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? =F0=9F=99=82 Th= at=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 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 sinc= e > 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=E2=80=99t want to waste thei= r 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 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. The= y > 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 in > 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 : > >> >> >> 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 st= ocks >>> 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 no= t >> 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 gre= at >> 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 t= he >> 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 kno= w >> every possible way PHP is used and the RFC process is here for people fr= om >> many backgrounds to provide their own perspective of things and voice ho= w >> 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 h= ow >> this RFC would play out in their projects and their work. It's far too b= ig >> of a change with too many concepts, mainly foreign to many people workin= g >> with PHP and there isn't a clear path of contributing to the discussion. >> >> How do we solve that? >> >> -- >> Marco Deleu >> > --=20 Marco Deleu --000000000000fb366f0648ec8c14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

Let's agree to disagree.
=C2=A0
For example, the Swoole project has existed for more than 7 years. Th= is 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=C2=A0useful for any proj= ect 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 o= ne of the top reasons why the RFC hasn't gotten more traction.
=C2=A0
There is already extensive exper= ience with Laravel and other applications.
All of th= is has existed for a long time.

Just because it has existed doesn't mean it is universally used.=
=C2=A0
If people cannot read t= he RFC and understand that these are JavaScript-style coroutines, then why = do they have votes? =F0=9F=99=82 That=E2=80=99s a strange idea.
=

I see this statement as you going ou= t 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 PH= P enough to have a vote. An ecosystem that has existed without Async PHP fo= r 3 decades. An ecosystem that requires thorough development, documentation= , release, testing, bug fixing, security fixing. They have volunteered thei= r 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 co= ntribution any less meaningful or any less important.

<= div>I can understand and sympathise that it must be very frustrating for yo= u 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 matte= r is. There's definitely an appetite to have Async PHP and you're n= ot 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 de= velopment of PHP for years. How can the RFC be easy to digest so that they = can participate more?
=C2=A0
Ye= s, there are issues with understanding. However, a year has passed since th= e publication. In one year, it should have been possible to clarify any que= stions, if there were any.

The RFC is complex enough that giving it chunks of 30 minutes spread acro= ss many weeks is not enough to put forward every question that it warrants.= 1 year or 10 years is not going to solve that.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
In other words, if PHP had never had such corou= tines, that could be understood. But the situation is exactly the opposite.=

As for trust, the probl= em is that people don=E2=80=99t want to waste their time. They don=E2=80=99= 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 p= romising change to the PHP Ecosystem, it would be in any volunteer's in= terest 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 organiz= ational changes.

I can o= nce 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 mor= e than one. For example, you could vote in a first 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>:
<= br>

On Wed, Jan 21, 2026 at 4:29=E2=80=AFPM Edmond Dantes <ed= mond.ht@gmail.com> wrote:
Regarding the group, I want to once again express an impor= tant 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
--000000000000fb366f0648ec8c14--