Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128885
Date: Tue, 21 Oct 2025 17:58:58 +0100 (BST)
To: Edmond Dantes <edmond.ht@gmail.com>
cc: Larry Garfield <larry@garfieldtech.com>, 
    php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
In-Reply-To: <CAMW7n8CAd3P1egRkeHBsrMk7YOEdiSvVgm5teyCZ7EOysC7q1g@mail.gmail.com>
Message-ID: <4e62d98b-24f8-166f-0ba0-0c65f8b06ec1@php.net>
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com> <CADuktwNP+t-DJbLCsnHHhztZYmOMGYde9rzNm+9B0SUsrNvV-g@mail.gmail.com> <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com> <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com>
 <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com> <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com> <CAMW7n8BWvf-bE6g7A_0vDW1Lf8hhTm-zuyNEY23DA0biNS-YSA@mail.gmail.com> <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
 <4f9b8dfd-5415-3df3-fda9-33a8716c57c1@php.net> <CAMW7n8BG=GsqrQ-D6rekRgYOg0y_SUJksio7Y-uQKSs97zixEg@mail.gmail.com> <d4c99ddc-d62f-4574-a798-80fa7b1d3e1c@app.fastmail.com> <CAMW7n8CAd3P1egRkeHBsrMk7YOEdiSvVgm5teyCZ7EOysC7q1g@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1226881089-1761064772=:4580"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1226881089-1761064772=:4580
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 14 Oct 2025, Edmond Dantes wrote:

> > It's vastly improved from the first version back in the spring, but the=
re are still numerous footguns
>=20
> Which specific footguns? $scope var?
>=20
> > Mainly, we should not be allowing anything but structured
> If you always follow the =E2=80=9Cnursery=E2=80=9D rules, you always have=
 to define a
> coroutine just to create a nursery, even when the coroutine itself
> isn=E2=80=99t actually needed.
> That=E2=80=99s why we end up with hacks like =E2=80=9CTask.detached.=E2=
=80=9D (*Swift*). And
> *Kotlin* keeps trying to invent workarounds.
>=20
> **TrueAsync RFC** takes a different approach and gives the programmer
> maximum flexibility while still complying with every principle of
> structured concurrency.
> At the same time, the programmer gains two styles of structured
> concurrency organization, one of which fully matches Trio.
>=20
> > I very much want to see it evolve further in that direction before a vo=
te is called and we're locked into a system with so many foot guns built in=
=2E
>=20
> Such an approach would require more changes to the code, and I don=E2=80=
=99t
> see how it would protect the programmer from mistakes any better than
> this RFC does.
> Of course, the with-style syntax would allow for maximum safety when
> working with tasks, but that=E2=80=99s not an issue with this RFC.
>=20
> The **Trio** model is not perfect; Kotlin and other languages do not
> adopt it (maybe by accident =E2=80=94 or maybe not).
> It=E2=80=99s not suitable for all types of tasks, which is why the critic=
ism is valid.
>=20
> Although Kotlin is criticized for storing Scope inside objects like:
> =E2=80=9CLong-living CoroutineScope stored in objects almost always lead =
to
> resource leaks or forgotten jobs.=E2=80=9D
> However, there is no other way to solve the problem when coroutines
> need to be launched within a Scope gradually rather than all at once.
>=20
> But... Ok...
> ```python
> async def background_manager():
>     async with trio.open_nursery() as nursery:
>         while True:
>             event =3D await get_next_event()
>             nursery.start_soon(handle_event, event)
> ```
> ^^^
> The example of how the pursuit of an =E2=80=9Cideal=E2=80=9D ends up prod=
ucing ugly code.
>=20
> My position is this: **TrueAsync** should support the best patterns
> for specific use cases while still remaining convenient for the
> majority of tasks.
> The fact that certain tools require careful handling applies to all
> programming languages. That doesn=E2=80=99t mean those tools shouldn=E2=
=80=99t exist.
>=20

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1226881089-1761064772=:4580--