←back to thread

Exploring Coroutines in PHP

(doeken.org)
116 points doekenorg | 2 comments | 05 Jul 25 09:34 UTC | HN request time: 0.001s | source
Show context
zelphirkalt ◴[08 Jul 25 10:55 UTC] No.44498859[source]▶
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.

replies(3): >>44498970 #>>44499101 #>>44503598 #
ahofmann ◴[08 Jul 25 20:09 UTC] No.44503598[source]▶
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.

replies(1): >>44508684 #
1. zelphirkalt ◴[09 Jul 25 11:28 UTC] No.44508684[source]▶
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.

replies(1): >>44518456 #
2. ahofmann ◴[10 Jul 25 07:53 UTC] No.44518456[source]▶
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.