# Why did fibers get added to php core over something more fleshed out like swoole?

- Thread: https://externals.io/message/121291
- Original archive: https://news-web.php.net/php.internals/121291
- Started by Lanre Waju on 2023-10-13T00:59:59+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #121291 — Lanre Waju — 2023-10-13T00:59:59+00:00

URL: https://externals.io/message/121291#121291

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.

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 came 
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 best 
interests of the PHP community. I would appreciate it if you could 
provide insights into why this might not be the case.


Lanre

---

## #121293 — Jordan LeDoux — 2023-10-13T01:30:21+00:00

URL: https://externals.io/message/121291#121293 · In reply to: #121291

> It sometimes seems as though certain choices may not align with the best
> interests of the PHP community. I would appreciate it if you could
> provide insights into why this might not be the case.
>
>
To find out why Fibers was done instead of something like Swoole, I'd
suggest reading the mailing list discussions on those. That was a
discussion that DID happen on list, and you can read about it there without
us rehashing it for no particular reason.

The way you ended this email though is very "guilty until proven innocent",
and I think it's unlikely you're going to get many responses based on the
way you phrased this and the implied accusation it entails.

This is coming from someone who has their own reservations about how PHP
voting is conducted. It's a discussion that very few people want to have
because of how drawn out and heated it is likely to be, and the fact that a
significant number of people don't see any problem with the current system.
Trying to start that conversation with "it seems obviously broken, prove me
wrong" sounds like just about the worst framing that discussion could have
if you want it to be productive.

Jordan

---

## #121294 — Lanre Waju — 2023-10-13T02:25:56+00:00

URL: https://externals.io/message/121291#121294 · In reply to: #121293

Can you provide insights into the "significant number of people" who 
support the current system without concerns? It appears that you might 
be representing a substantial portion of such individuals. I did attempt 
to explore the mailing list discussions, but they did not yield 
conclusive answers, which is why I felt it was necessary to inquire 
directly. I hold no preconceived biases on this matter; I'm seeking a 
better understanding of the issue and the perspectives surrounding it.

Lanre


> 
>
> > […]
> To find out why Fibers was done instead of something like Swoole, I'd
> suggest reading the mailing list discussions on those. That was a
> discussion that DID happen on list, and you can read about it there without
> us rehashing it for no particular reason.
>
> The way you ended this email though is very "guilty until proven innocent",
> and I think it's unlikely you're going to get many responses based on the
> way you phrased this and the implied accusation it entails.
>
> This is coming from someone who has their own reservations about how PHP
> voting is conducted. It's a discussion that very few people want to have
> because of how drawn out and heated it is likely to be, and the fact that a
> significant number of people don't see any problem with the current system.
> Trying to start that conversation with "it seems obviously broken, prove me
> wrong" sounds like just about the worst framing that discussion could have
> if you want it to be productive.
>
> Jordan

---

## #121295 — Deleu — 2023-10-13T02:28:38+00:00

URL: https://externals.io/message/121291#121295 · In reply to: #121291

On Thu, Oct 12, 2023 at 10:00 PM Lanre Waju <lanre@online-presence.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 Fibers
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 came
> 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 best
> 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 PHP
had a significant history of decisions that made future work on the
language harder. As time passed and the language had more and more features
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 history
is to become more conservative. Userland libraries can have faster release
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 discussions
never led to a concrete implementation.

As it currently stands, PHP is a solid language with stable and proven APIs
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 significant
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 arrow
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

---

## #121296 — Robert Landers — 2023-10-13T07:35:15+00:00

URL: https://externals.io/message/121291#121296 · In reply to: #121295

>
> On Thu, Oct 12, 2023 at 10:00 PM Lanre Waju <lanre@online-presence.ca>
> wrote:
>
> > […]
>
> Seems like your description here quite matches what the goal/aim for Fibers
> initially was; a low-level API to help userland libraries to build async
> PHP code.
>
>
> > […]
>
> My personal, non-fact-checked guesswork about the current state is that PHP
> had a significant history of decisions that made future work on the
> language harder. As time passed and the language had more and more features
> 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 history
> is to become more conservative. Userland libraries can have faster release
> 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 discussions
> never led to a concrete implementation.
>
> As it currently stands, PHP is a solid language with stable and proven APIs
> 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 significant
> 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 arrow
> 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.

---

## #121315 — Rowan Tommins — 2023-10-14T22:48:35+00:00

URL: https://externals.io/message/121291#121315 · In reply to: #121291

> It sometimes seems as though certain choices may not
> align with the best interests of the PHP community. I would
> appreciate it if you could provide insights into why this
> might not be the case.

Leaving aside the specific examples for a moment, the basic answer to this is "because we're human". Even the best designers in the world do things that they'd change if they could do it over, or agree to compromises that cost more than they initially realised.

In fact, we're probably more "only human" than you think. By that I mean that from the outside, it's easy to assume there's an elite team of Language Designers, sitting on some kind of PHP Committee; but the reality is very different. There's just a bunch of people who sign up to this mailing list, and chat in a few other places, and try to figure out how to make the language better without breaking billions of lines of existing code. Don't get me wrong, some of the people here are amazing at what they do, but few if any do this full time or are even paid at all (head to https://thephp.foundation/ if you want to help grow that number).

That means the project is and always has been run on collaboration and compromise - features that someone has time to implement, architectures that multiple people are happy to work on together, solutions that move things forward without making the perfect the enemy of the good.

Sometimes the answer to "why doesn't X do Y?" is just "because nobody's stepped forward to implement it yet"; sometimes it's "nobody's worked out how to do it without breaking Z"; in which case, feel free to volunteer that time, or solve that issue. But, yes, sometimes it's "because we had a long and tiring debate, and ended up with a compromise that nobody really likes"; or "because the lack of official leadership and a relatively high turnover of contributors makes us pretty bad at longer-term planning".

As Jordan said, if you really want to have a productive discussion about a feature, try to come across more positively, e.g. "I was thinking it would be useful if the language had this feature, and was wondering if it's been discussed before?" Bonus points for adding "... and if there's a way I can help add it?"

Regards,

-- 
Rowan Tommins
[IMSoP]