Exploring Coroutines in PHP

I think neither does PHP have the ecosystem for it, nor does it have the language primitives or standard library for it. Much cleaner languages than PHP already have enough issues getting concurrency things like fibers right. I don't see this ending in any implementation, that doesn't have surprising dysfunctional parts in it. Especially not, when again and again people behind PHP chose the easy way out for adding language features, like they did with lambdas, that don't capture their environment, unless you explicitly state what they capture.

Let alone the standard library being an unfixable mess, if they want to pursue backwards compatibility. What they would need to do is a clean break. Something like "PHP 10 is a breaking change, we are modernizing the base language and standard library and getting rid of decades of cruft." -- Which then many PHP users would hate.

No, PHP is a not a language whose design has what it takes. A library that claims to have such advanced stuff implemented in PHP is not to be easily trusted to be free of hassle and tripwire, because the language itself has those built-in. For example with Fibers, one has to manually call suspend and resume. Other languages get fibers done without this hassle.

EDIT: For all the downvoters, who don't care to actually give reasons or discuss, the cracks are already showing in the Fibers manual itself. Look at the first comment for example: https://www.php.net/manual/en/language.fibers.php#127282 which links to a bug/issue in the Fibers repo. It is a bug, even recognized via issue label, it is verified, as recognized via issue label, and it is ... closed. Apparently it will not be fixed, and has been simply closed.

> like they did with lambdas, that don't capture their environment

https://www.php.net/manual/en/functions.arrow.php

The standard lib thing is overblown. What exactly is bothering you?

And PHP has deprecated a lot of things along the way.

Yes this exists, but again introduces a new thing into PHP, rather than using an existing thing. Instead of using existing function syntax and leaving away the name, now one has 2 more things: The "fn" (why can this not be "function" which already exists?) and in combination with "=>". So it is similar to "function ... use ..." which also has the need to introduce a new thing, the "use", instead of simply capturing its environment.

The point is, that the designers of PHP decide again and again to add another wart, rather than designing the language in an extensible way. Here a little extra, there a little extra, here a new keyword, there a new thingy. Compare that with other languages. Even JavaScript has managed to have simply the same syntax for functions and anonymous functions. Although it did also introduce an arrow syntax. However it's arrow syntax is not really needed, even though shorter, in contrast to PHP, where you need it, unless you want to list all the parts of the environment you need in the anonymous function. At least in JS they didn't introduce a new extra thing like "fn".

I don't think the design of PHP is done with good oversight. It is done with the approach of tacking things onto what exists, in the easiest way they are able to do, without any goal of keeping the language concepts and keywords minimal. Designing something like "fn" or "use" is a hack to make implementation easier, because they are previously unused keywords, that will then make it easier to adapt the parser for the language, but these decisions are offloading mental load to the user, which ultimately is a bad design.

PHP watched the absolute disaster of python 2 to 3 version upgrade and rightfully decided that it will be as much backwards compatible as possible.

PHP 10 with a clean slate is a cute idea that would wreak havoc. Perl, or whatever it is called now, tried this and it was a total disaster.

You might say "PHP is a fractal of bad design"...

I personally never perceived Python 2 to 3 as a disaster, and the language has come out better on this end. It would have been a disaster to keep all the cruft of Python 2 forever and keep writing software in it. When Python 3 became stable, I simply never looked back at Python 2 again. Sure, many libraries had to change a bit, to accommodate Python 3. But any sane project would start with Python 3 anyway, and over time Python 2 support would simply fade away, as fewer and fewer people use it. Maybe during some transitional time people had backports of security fixes for Python 2, but in this day and age I wouldn't actually bother with that any longer. Whoever still runs on Python 2 has made a decision to do so, accepted responsibility for not transitioning and has no one but themselves to blame.

Overall they actually did a pretty decent job to transition from Python 2 to 3. Many people didn't have any issues at all, and simply used the new thing instead of the old thing.

Python's language design in itself is debatable of course, but it certainly is better now than with Python 2.

I was maintaining some debian servers back then, and for more than a decade there was great confusion around python. What you describe as "Sure, many libraries had to change a bit" was a major pain in the butt for many people for many years. I'd describe this as a disaster. The "just start a new project"-mentality is not what happens on servers and companies of the world. They support stacks, that are literary decades old.