Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129340 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 4D7041A00BF for ; Thu, 20 Nov 2025 18:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763662462; bh=FSFa1uGWvN1cCnuBcSt9Tm/+gqly4S3dYAtaVUPf5Ig=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gqGlmcxlKZty1PKfAlhs5EgSr4TuFGrMiqdEb2Ydl3AIKcZEVsMYo81kAkhUke6ya 6C4muMX2NyN4hWGz9I02wNgk9LRxsX7GuG/Oi1j51/NtwReiTRhR195u1RE/qearBC VJIM5VEqffgqZ/Zv5xy0e80DeUVlQck55C8OscI6zk9nvpO76TR7p5w6SVBpZw+pod ta17yNUWqMeSv2XAlnl7NSi4O1p/KnUt+XmzOoP7X9TzVKbvSfA10q9eP3YZsjy03f yD2c9WAyrHfo6yyvZFxdKvt5pBd7qUoaYUPG++gYjIo0WdaumikIJyJQhZX9V+tyIZ RaTVSb7OB7UxQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 536451807F5 for ; Thu, 20 Nov 2025 18:14:20 +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=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-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 ; Thu, 20 Nov 2025 18:14:17 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-59431f57bf6so1229752e87.3 for ; Thu, 20 Nov 2025 10:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763662451; x=1764267251; 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=i4qDR9lhB3kUMKhogcfuPBIg2jAM3VvRx4yoHxpvd0E=; b=DuPV5Wgd0fkI9vsmYDKkMl7W0rEy2EGxQ5W9R6Z5ZAneFBwYvCWsTot9XskqzrGyA/ Zwgt1OHOTNwKNUAiNSf6696yo/osgxZNTwbgJHSV+6QgWuYNj7CnOUio/IT2ea6duOWE iAsOhcrnKkHGAGjiRIuyWcMaslb36cqsUO21j9XX/cy73E9GDTI+GkDAhrOljdqcJy4X 9Ps9fYkyDuVE7SlxOVwF1Jtjc7I47e42RPzOPDv0eW+yjddYu59trD4cuiGbPuqZZDye KYr3cJYGgEjSPKMHocYbIp5tq+VFhbhHPb8v6me+/wYOVCIGDRrWdDXbW4vVl++bhcT+ nPQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763662451; x=1764267251; 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=i4qDR9lhB3kUMKhogcfuPBIg2jAM3VvRx4yoHxpvd0E=; b=dMRks3CIVf/kCSssyQYHn1uh20QfjuJUVsvZx+WkiFlxmRCJYHtDep6Zdqf6W4HmeV 8rXKVM5YX1FWdczIqSoQLNMcZmKWgv0PVcLlGe61MRXifPY2ZhGDizQQttwFoILje3Yl /iQMpqpQPGWkrxBKjN7uMy1IV0W5K2/fGgxVgm/rwBjzHSex6wTVUEqtchZ0F5SbSkJX vfQotL8ZT41HK0RNfnjulB2gkmV3TvmxY/YjnR0/0yUxTYPT86oRN+vxMUHh7WRfq9kT jGTDYt0KN1lTi1FVjXbTc9wXPFBLhg52QqL7JgWIYqapokIHpQXWCAZfMLzUOkBoZqqZ Xo4w== X-Forwarded-Encrypted: i=1; AJvYcCWGwc44FptZ4g0vLUha2CoIpYUR2cmCw089WiGWWkj2was/PvceLG8QHhOlXDSXm5SjcXKrN+hs8uU=@lists.php.net X-Gm-Message-State: AOJu0Yy+nveGCfnT3pFyA1DXV/EHJ429TYnjhGeLpJeSmLzayUgSw96v EKuQhBhZeS+qByLjUEbnkFrpVqLz1ZDo6Q+DXbprNdIMR7cS9t1EcMckKYLHq5BkMXsdq0KQFgL yqVcVLV7G1UmjrIbjJKtz58T76LJXQx4= X-Gm-Gg: ASbGncuzohT7DHIvyve+YqLGrOyTNTj6+lWLyfYQJ9102n1xG+Eec2wCDBaamfhvHMn f8wFiX6EvgasvFeuPLQ/p/Xr09azhL+JOAXcz76K08gcKU8nwRbtXH+HJfkS9paVLTKuSGKcpmQ usMYKj7OwtwChWg4tN8sYTbYpxq/bCOGoVSy+ayQWdjab1Rxi12LQ7CVacakuGSC2NthcTAe7Cr I4nhdV15E5F7yrV3OGBAdWgx+7UrHmbZQo3g4DhzoeODD7hQCIcKT1QgD6N7dFF3kCMcgzGLFf4 HBZGaCUJImitibkNWkua4U3YVGHq X-Google-Smtp-Source: AGHT+IHlftlFR32OM3hBuyjmjr8hyaDaGUINszVSafXauL+ZTxUV9kZzzA0jgPZeUj1REFz21AD0+owPdaU3igoUaYU= X-Received: by 2002:a05:6512:3054:b0:594:5000:4555 with SMTP id 2adb3069b0e04-5969e2f73a0mr1439233e87.29.1763662451074; Thu, 20 Nov 2025 10:14:11 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 20 Nov 2025 15:13:58 -0300 X-Gm-Features: AWmQ_bnBhgMNzErhurd1TBYzKqLL2IJijJZ8lb9QNoznpyxOCPqBQbcLFJazJW8 Message-ID: Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6 To: Jakub Zelenka Cc: Deleu , Daniil Gentili , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000e66a0206440aa930" From: luisvscbarros@gmail.com (=?UTF-8?Q?Lu=C3=ADs_Vin=C3=ADcius_Santos_da_Costa_Barros?=) --000000000000e66a0206440aa930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi What I understand from this is that the voters are not willing to make any concessions to include a feature that is important to at least 10% of the developers in the PHP ecosystem (someone mentioned 10% in an earlier email; I would guess the number is even higher, considering China). It=E2=80=99s i= mportant for us, who are part of that 10% that apparently isn=E2=80=99t important en= ough to be heard, to know what the voters=E2=80=99 stance actually is regarding the introduction of tooling for Async in PHP. That way we can understand what the next step needs to be: whether we take on the difficult job of migrating our software from PHP to another platform, or the impossible job of trying to convince people who are not willing to be convinced. Regards, Lu=C3=ADs Vin=C3=ADcius Em qui., 20 de nov. de 2025, 12:44, Jakub Zelenka escreveu: > On Thu, Nov 20, 2025 at 1:04=E2=80=AFPM Deleu wrote: > >> On Thu, 20 Nov 2025 at 07:21 Daniil Gentili >> wrote: >> >>> Hi, >>> >>> >> Hello Bart. >>> >> I am ready to agree with every word. >>> >> >>> >> Participation from a working group, framework representatives, and t= he >>> >> ability to adapt libraries in advance would remove the concerns that >>> >> are currently causing fear. This is probably the only effective >>> >> process for developing and introducing such a feature. >>> > >>> > Then two days later, you decided that no more discussion was >>> > necessary, and opened a vote. >>> > >>> > This feels like a complete contradiction. >>> > >>> > Let's find a way to get that working group set up, and get people fro= m >>> > other projects involved. >>> > >>> >>> My key takeaway from Bart's message is: >>> >>> > Moreover, even though there are quite a few people in the community >>> who have the knowledge required because they either develop or work wit= h >>> aforementioned libraries or extensions, (almost) none of them seem to b= e >>> involved in discussing this RFC. >>> > For an RFC that can drastically change the way we develop >>> applications I would expect more experts on this matter to be involved. >>> Ideally, PHP core developers, library developers & maintainers, IDE >>> developers, ..., would develop software using this branch to at least >>> get some feel for the paradigm and this RFC in general. >>> >>> 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, and thus haven't: >>> >>> - Experienced the pain of writing async with colored functions >>> - Experienced the footguns of structured concurrency >>> - And on the other hand, haven't experienced the pleasure and simplicit= y >>> of safely writing async code in languages like Go, or in PHP using AMPH= P >>> (which use uncolored and unstructured concurrency, the kind proposed an= d >>> championed by edmond) >>> >>> While a working group *can* steer the conversation away from >>> theoretically correct but practically unusable approaches, that can >>> happen only if >>> >>> - The correct people (i.e. async library maintainers, or people that >>> write async logic every day in multiple languages like myself) are >>> present >>> - They are given more weight than the average PHP developer who hasn't >>> used async much if at all, and can only make theoretical proposals not >>> based on practice and experience >>> >>> I'm afraid that given the current state of the PHP community, which is >>> largely new to async, the quality of the conversation in a working grou= p >>> would not be much higher than the one I'm seeing in this RFC, and would >>> just protract even longer the agony of design by committee, where in >>> reality what's needed is a single, clear and correct vision (which >>> Edmond has), without influences from unexperienced people making >>> proposals based purely on abstract/theoretical PoVs. >>> >>> Regards, >>> >>> Daniil Gentili. >> >> >> While I certainly can sympathize with the painful, dreadful, unpleasant, >> unbearable agony of debating a subject with =E2=80=9Cnon-experts=E2=80= =9D, it=E2=80=99s important >> to have some perspective in the opposite direction. >> >> As it has been mentioned before, Async PHP in general is practically a >> rounding error in terms of user base and there are reasons for that. It= =E2=80=99s >> important to remember that the benefits of async doesn=E2=80=99t always = justify the >> burden that it brings. For PHP as a language to adopt an async solution >> natively it=E2=80=99s very important that sync code continues to functio= n while >> also allowing developers to opt into async without having to feel like t= hey >> changed languages and must re-learn how to manage their projects. If thi= s >> is not possible then perhaps the current state is as good as we can ever >> get: let expert matter install their extension (opt-in) on a per-project >> basis. >> >> It's going to be up to the subject experts to come up with a path that >> allows PHP to stay coherent while offering both approaches. To put this = in >> another way: RFC Voters are above average PHP developers. If they're una= ble >> to digest the changes being proposed, even if said changes are being >> proposed by the single most subject-expert human on the planet, then how= do >> we expect average PHP developers to make good use of it? >> > > Yeah I think this is one of the reasons why the RFC failed. It couldn't > properly explain the topic even though it was reduced to minimum. One of > the factor is certainly that Edmond is new to the RFC process but more > importantly it's quite contentious topic that can bring even more bike > shedding. I think there were some important points raised in the > discussions about safety of the existing sync code which I think might be > the real killer here. So even if we omit the mix up with the > pre-announcement and sudden voting (that were sure path to rejection), I > think the bigger problem is the whole size of the feature and the fact th= at > it will be extremely hard to find any solution that will please majority = of > voters. I'm honestly not sure if this is possible to get to any form that > can pass. I would like to be wrong but we can see the reality here. > > I think the way forward for PHP is to do what we have been doing and it i= s > to provide the building blocks for user space to enable async there becau= se > that's something that can be reasonably introduced using the RFC through > smaller chunks. It means improving the non blocking setup, exposing IO > hooks, better polling and other primitives. That was actually the plan in > past and that's why it is also contained in my STF stream work where the > scope was created way before the TrueAsync. > > Kind regards, > > Jakub > --000000000000e66a0206440aa930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Wha= t I understand from this is that the voters are not willing to make any con= cessions to include a feature that is important to at least 10% of the deve= lopers in the PHP ecosystem (someone mentioned 10% in an earlier email; I w= ould guess the number is even higher, considering China). It=E2=80=99s impo= rtant for us, who are part of that 10% that apparently isn=E2=80=99t import= ant enough to be heard, to know what the voters=E2=80=99 stance actually is= regarding the introduction of tooling for Async in PHP. That way we can un= derstand what the next step needs to be: whether we take on the difficult j= ob of migrating our software from PHP to another platform, or the impossibl= e job of trying to convince people who are not willing to be convinced.
=

Regards,

Lu=C3=ADs Vin=C3=ADcius=C2=A0
Em qui., 20 de nov. de 2025, 12:44, Jakub Zelenka <bukka@php.net> escreveu:
On Thu, Nov 20, 20= 25 at 1:04=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
On Thu, 20 Nov 2025 at 07:21 Daniil Gentil= i <daniil.gentili@gmail.com> wrote:
Hi,

>> Hello Bart.
>> I am ready to agree with every word.
>>
>> Participation from a working group, framework representatives, and= the
>> ability to adapt libraries in advance would remove the concerns th= at
>> are currently causing fear. This is probably the only effective >> process for developing and introducing such a feature.
>
> Then two days later, you decided that no more discussion was
> necessary, and opened a vote.
>
> This feels like a complete contradiction.
>
> Let's find a way to get that working group set up, and get people = from
> other projects involved.
>

My key takeaway from Bart's message is:

=C2=A0> Moreover, even though there are quite a few people in the commun= ity
who have the knowledge required because they either develop or work with aforementioned libraries or extensions, (almost) none of them seem to be involved in discussing this RFC.
=C2=A0> For an RFC that can drastically change the way we develop
applications I would expect more experts on this matter to be involved. Ideally, PHP core developers, library developers & maintainers, IDE developers, ..., would develop software using this branch to at least
get some feel for the paradigm and this RFC in general.

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, and thus haven't:

- Experienced the pain of writing async with colored functions
- Experienced the footguns of structured concurrency
- And on the other hand, haven't experienced the pleasure and simplicit= y
of safely writing async code in languages like Go, or in PHP using AMPHP (which use uncolored and unstructured concurrency, the kind proposed and championed by edmond)

While a working group *can* steer the conversation away from
theoretically correct but practically unusable approaches, that can
happen only if

- The correct people (i.e. async library maintainers, or people that
write async logic every day in multiple languages like myself) are present<= br> - They are given more weight than the average PHP developer who hasn't =
used async much if at all, and can only make theoretical proposals not
based on practice and experience

I'm afraid that given the current state of the PHP community, which is =
largely new to async, the quality of the conversation in a working group would not be much higher than the one I'm seeing in this RFC, and would=
just protract even longer the agony of design by committee, where in
reality what's needed is a single, clear and correct vision (which
Edmond has), without influences from unexperienced people making
proposals based purely on abstract/theoretical PoVs.

Regards,

Daniil Gentili.

= While I certainly can sympathize with the painful, dreadful, unpleasant, un= bearable agony of debating a subject with =E2=80=9Cnon-experts=E2=80=9D, it= =E2=80=99s important to have some perspective in the opposite direction.

As it has been mentioned b= efore, Async PHP in general is practically a rounding error in terms of use= r base and there are reasons for that. It=E2=80=99s important to remember t= hat the benefits of async doesn=E2=80=99t always justify the burden that it= brings. For PHP as a language to adopt an async solution natively it=E2=80= =99s very important that sync code continues to function while also allowin= g developers to opt into async without having to feel like they changed lan= guages and must re-learn how to manage their projects. If this is not possi= ble then perhaps the current state is as good as we can ever get: let exper= t matter install their extension (opt-in) on a per-project basis.

It's going to be up to the su= bject experts to come up with a path that allows PHP to stay coherent while= offering both approaches. To put this in another way: RFC Voters are above= average PHP developers. If they're unable to digest the changes being = proposed, even if said changes are being proposed by the single most subjec= t-expert human on the planet, then how do we expect average PHP developers = to make good use of it?

=
Yeah I think this is one of the reasons why the RFC failed. It couldn&= #39;t properly explain the topic even though it was reduced to minimum. One= of the factor is certainly that Edmond is new to the RFC process but more = importantly it's quite contentious topic that can bring even more bike = shedding. I think there were some important points raised in the discussion= s about safety of the existing sync code which I think might be the real ki= ller here. So even if we omit the mix up with the pre-announcement and sudd= en voting (that were sure path to rejection), I think the bigger problem is= the whole size of the feature and the fact that it will be extremely hard = to find any solution that will please majority of voters. I'm honestly = not sure if this is possible to get to any form that can pass. I would like= to be wrong but we can see the reality here.

I th= ink the way forward for PHP is to do what we have been doing and it is to p= rovide the building blocks for user space to enable async there because tha= t's something that can be reasonably introduced using the RFC through s= maller chunks. It means improving the non blocking setup, exposing IO hooks= , better polling and other primitives. That was actually the plan in past a= nd that's why it is also contained in my STF stream work where the scop= e was created way before the TrueAsync.

Kind regar= ds,

Jakub
--000000000000e66a0206440aa930--