Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121296
MIME-Version: 1.0
References: <0b72d5e0-94dc-8837-bfd4-d2e24ab9db05@online-presence.ca> <CADK1yXL2_Rqdj=FgVwG8ydT5iyh8PAvw0meDjVEVMXsLt9k-Ow@mail.gmail.com>
In-Reply-To: <CADK1yXL2_Rqdj=FgVwG8ydT5iyh8PAvw0meDjVEVMXsLt9k-Ow@mail.gmail.com>
Date: Fri, 13 Oct 2023 09:35:15 +0200
Message-ID: <CAPzBOBOZZ7x7wiuXT0jnYCq=8Va0qEa_ieEL3AMB_=QGsEx3_w@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Lanre Waju <lanre@online-presence.ca>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Why did fibers get added to php core over something
 more fleshed out like swoole?
From: landers.robert@gmail.com (Robert Landers)

On Fri, Oct 13, 2023 at 4:29=E2=80=AFAM Deleu <deleugyn@gmail.com> wrote:
>
> On Thu, Oct 12, 2023 at 10:00=E2=80=AFPM Lanre Waju <lanre@online-presenc=
e.ca>
> wrote:
>
> > I find it puzzling that the PHP internals have chosen to delegate this
> > specific functionality to userspace implementation. Fibers, in my view,
> > seem somewhat limited without the addition of a third-party library or,
> > at the very least, the necessity to implement an event loop in userland=
.
> > This raises questions, as it effectively obliges users to rely on
> > third-party libraries to handle a fundamental feature rather than
> > incorporating it into the core of PHP.
> >
>
> Seems like your description here quite matches what the goal/aim for Fibe=
rs
> initially was; a low-level API to help userland libraries to build async
> PHP code.
>
>
> > Moreover, I'm curious about why PHPDBG doesn't implement the Language
> > Server Protocol (LSP). Could it be due to its reliance on Xdebug? I cam=
e
> > across this discussion on https://externals.io/message/78456, which
> > makes me wonder about the decision-making process within PHP internals.
> > It sometimes seems as though certain choices may not align with the bes=
t
> > interests of the PHP community. I would appreciate it if you could
> > provide insights into why this might not be the case.
> >
> >
> > Lanre
> >
>
> My personal, non-fact-checked guesswork about the current state is that P=
HP
> had a significant history of decisions that made future work on the
> language harder. As time passed and the language had more and more featur=
es
> naturally the project becomes harder to maintain and navigate, which
> affected how future decisions were made. The BC promise of PHP has always
> been significantly high - some edge cases and significant BC breaks have
> happened, but they're not the norm. Naturally the next step in this histo=
ry
> is to become more conservative. Userland libraries can have faster releas=
e
> cadence, requires PHP maintainers (bigger pool than C maintainers) and
> breaking changes are a lesser problem to a certain extent. Discussions
> around language evolution, editions, etc has happened as (among other
> things) a possibility to make BC breaks less impactful to the world wide
> web and lower the barrier in getting an RFC approved, but these discussio=
ns
> never led to a concrete implementation.
>
> As it currently stands, PHP is a solid language with stable and proven AP=
Is
> with Composer and Community packages covering the gap in consistency,
> technology evolution and developer experience. I'm a big advocate for
> having some language changes that makes common and fundamental use-cases
> part of the language i.e. it's quite unfortunate that a 30 year old
> language that powers the World Wide Web don't have a Request object, but
> history has made PHP quite conservative and there hasn't been a significa=
nt
> change that invalidates the reason to be conservative yet. On top of that=
,
> some voters are extra conservative when the topic is added DX built-in to
> the language, specially because DX can be subjective (see multi-line arro=
w
> function).
>
> Long story short, Fibers being something "incomplete" from a userland
> perspective is a feature, not a bug. Look at it as the simplest, smallest
> (while still being feature-complete) way to expose the ability to write
> async code in PHP while Swoole is almost an ecosystem on its own.
>
>
> --
> Marco Deleu

To add to this as a dev who uses fibers quite a bit, they are a
fantastic way to jump up a stack without using exceptions. Basically,
if you are using exceptions for flow control, fibers are usually a
good replacement. My only real issue with fibers is that when using
nested fibers, you can't control which one you suspend to, you just
suspend to whichever one is currently running. So, if you are writing
a framework and call into a user's code, and they create a fiber and
then call into your code that suspends ... there is a significant
chance everything will explode. This makes creating frameworks that
take advantage of fibers very hard because you have no way to protect
your code (or your user's code) from exploding everything because they
decided to use some async library that created a fiber. That's my only
complaint though, because for writing applications, fibers are amazing
when used well.