Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129325 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 AD8C91ADBD9 for ; Thu, 20 Nov 2025 11:55:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763639745; bh=GJt/gMEivvNEuaOHXiRPdIi1FdO6v11LzRs5rGqYzzw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oQR/36Yi1RJjF2DsacPGPzhHEEw7E62bGZY72uh5y/CpmEixvW/9zQimBu1IGKbxE g8nvdUt5SXyAfas8t7uX2rhogKqj9QXOfM4HRgXrmWY85RmDXnN3XMtFdY036szH1Z OaTq1MYYK4eD4YK8Mp3dPHhi36yRxKRD3VXQJtm8CVLiOIWkTLo9PQYsRcQoVkIyDD aRSCjnhVwXvhdBkoIfozrZ0GBY3x1/sJgFW8UVgCnfjpiiKN+zR4LCg3VMPsin0urX O7rUj+WTmomv2BqxdJeFy5Am6dQAuYc9DSb06RwsfuTVW7fFPTnnuQvyQG5gcrY+dn GXLLsGlAPXXqw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 29D8C18069D for ; Thu, 20 Nov 2025 11:55:42 +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_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 11:55:37 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-299e43c1adbso951365ad.3 for ; Thu, 20 Nov 2025 03:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763639732; x=1764244532; 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=+pmfCk1zjEqJ3+c5KmajHj88ztnEl6EKd/YiJNuMM6Y=; b=hux9Txodl1dOv/ikVnXyVVbol4VIQFk77tVw9vYeCyJ9AA+/Dj2Vg0UFvvPlXYQ2nx N6r2oCbhW+6pMLzhVpXf6A2f5WRSjvVYORITgwMKe2Uq/4LWL44Y4/EfaJaLopGWzKor TuikSDQd+WJMxKptTq9HSuuuolc8NsHrZyN1ENsqGd3ohQMqiUKkmQt3ZCq8QxHIA/G1 zphVED4BSmT2F0PUD36CkRT3rT0e9bFSBMZsDjiSHk5V8c60EtzBad3MrMMJwwZBk5lB JKc3C2V6HxccCxME9nkh2RSBU41SL7m7hHY0mkpOq5qYU+wNIGta+Foj4OGV1p+3XDK/ 3LRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763639732; x=1764244532; 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=+pmfCk1zjEqJ3+c5KmajHj88ztnEl6EKd/YiJNuMM6Y=; b=llfBuV4foM+dpHzfoOQLvCaIJWXsVef27BfPSzYUza1yUn0xyPItA1PKgcBefQLB/4 pcmIYcUido1AR+JPKerD7ZSM4NOQVH26IJQkYuM3DcbuLjYebiMM/hOLK63wf2Yso34b 5zWyhhv5HWXko2KHOwabSg/fp2VDPSqfnq6dn2neZkrKa22s4Z5qNmCJPi+RQqgcZ6BN NmvU2xqc3pc58r/tD6qx4k/IjcTUlUdbS8NoXTTXUgWFyd/2WL5WOiB9CJadr28s6HOc 2BWPVUlE8oPc5A05C7tKXtEwMOv8kJY3S2yiob/8z8Apxt2m1tAefjbtO9sbCgzoVJjN FnMw== X-Gm-Message-State: AOJu0YzdIYO/V33cx+Fj7k9kTsyInCThwYpC84M8Xj/V9m6YYKhyFhWK eCxzMFI4JxpYo/7wvLAxTr6fsYyyrfSCJjH3X612qxVCW/dWZHXnC4naDQZYNwRg0jXBmUx4wch pgziED5GPA5todrp5a5+Iiur8A7Kg0TXcKHR2 X-Gm-Gg: ASbGncv5XWLpaSXgG1jufx0UTBvjQyY7Ekvz6ji48QW/h3U8Y7RgxNGgGcHN7SLChif 4tgquKVN8ehHL+qmWN8BUpUAr7Oa5Xku7ojwlfO0zitU9TLreaffE0GECY0LnBv5YpayQ5w5B0X M1shxvvDnRMAS+z3SfbrJFDFhD6EnpOXVztYg262o7eXEupkYFE/zjerO3G37RhzuLvv3qSw170 DpNJ6PKKgwd3iFOgBJfHLIjQjHkdle+M1qY1xz8jj5+hfvC/Mgnw0m9jApskQsAkUaKfJxq2XiA gT5VPPHPZ2jQAzn6TGz0+6BAyII= X-Google-Smtp-Source: AGHT+IFortTV6Iep8bas9b49RFJkJbqvFHtj7lLSvn9M16XU1kmfP25LnPpevsK8tpvZUATiN5Oer48KdZadUqcSyyM= X-Received: by 2002:a05:690e:11c4:b0:63f:b366:98d4 with SMTP id 956f58d0204a3-642f9dd1781mr835110d50.1.1763639264378; Thu, 20 Nov 2025 03:47:44 -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 08:47:08 -0300 X-Gm-Features: AWmQ_bmM8vQYD2-ERIpMipN9HVTpCtBTlNZKtpFvpTzNzHGOKXOaUw4cugQDG3U Message-ID: Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6 To: Daniil Gentili Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000dd828c06440543e8" From: deleugyn@gmail.com (Deleu) --000000000000dd828c06440543e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the > >> 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 from > > 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 with > aforementioned libraries or extensions, (almost) none of them seem to be > 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 simplicity > 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 presen= t > - 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, 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 jus= tify 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 w= hile also allowing developers to opt into async without having to feel like they changed languages and must re-learn how to manage their projects. If this 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 unable 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? --000000000000dd828c06440543e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 20 Nov 2025 at 07:21 Daniil Gent= ili <danii= l.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, unbearable agony of debating a subj= ect 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 pr= actically 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 c= ode continues to function while also allowing developers to opt into async = without having to feel like they changed languages and must re-learn how to= manage their projects. If this is not possible then perhaps the current st= ate is as good as we can ever get: let expert matter install their extensio= n (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 p= ut this in another way: RFC Voters are above average PHP developers. If the= y're unable to digest the changes being proposed, even if said changes = are being proposed by the single most subject-expert human on the planet, t= hen how do we expect average PHP developers to make good use of it?
--000000000000dd828c06440543e8--