Exploring Coroutines in PHP

Unfortunately, as HN has had more users, the quality of discussions has gone down a bit and is flooded with routine complaining of this kind.

You just discovered what happens when you talk about PHP, and there are similar "Godwin's laws" for other topics, such as IPv6 (we needed IPv4 with extra octets), Google/Apple/Microsoft (any company trying to achieve a commercial objective is always equivalent to "enshittification") etc. Don't mind these too much - it's a good article!

I have a service using them a lot. It ultimately relies on a couple dozen downstream dba and endpoints, with some calls requiring strict dependencies, and others running in parallel. So I just draw the dependency chart among the functions, and let the service manage all the parallelism and asynchronous bits with minimal babysitting. If it was all chained, then sure, it's not a significant gain

Fibers are incredibly powerful, as they can be used to implement seamless go-like concurrency with async, colorless functions.

They were added to PHP by the maintainers of amphp (https://amphp.org), which is the best library for async PHP out there, providing a clean, object-oriented and async API for files, databases and everything that can make use of async I/O.

I once had a use case where I wrapped a callback based library (Amazon's S3 library I think) call to instead return an iterator. Couldn't do that with only a generator since you can't yield in the callback itself. And it wasnt possible to write a custom iterator class since the library didn't give you back control until it was done.

That was the first and only time they were kinda useful to me.

This means, that most likely the keyword will not be "yield". PHP is not known for keeping a low number of keywords. Rather they introduce new ones, to tack on things to the language, like one can see in the implementation of anonymous functions, where one needs to use "use" explicitly, instead of the language having the semantics that most other languages have for lambdas. Which immediately turns in to a source for nullability errors.

I'd use `yield from` more if I didn't have to re-index arrays before yielding from them:

    function numbers() {
      yield from [1,2,3];
      yield from [4,5,6];
    };
    
    foreach (numbers() as $k => $v) { echo "$k => $v\n"; }
    0 => 1
    1 => 2
    2 => 3
    0 => 4
    1 => 5
    2 => 6

Yes, there is! However, even if the `iterable` it was yielding from a different Generator, the "outer" generator would still be "running", which still makes it asymmetrical. `yield from` is mentioned in the other post on Generators, though.

I work daily with PHP and honestly nearly all my code I write is synchronous.

The shared-nothing architecture of PHP makes that really a non-issue for me. Requests never share any state with each other. Something like RabbitMQ can handle communication between systems.

It's better to build your app in e.g. PHP, prove its worth, then identify the bottlenecks, THEN determine if you need multi-threading. And if so, determine if PHP would be the best language for it or if you'd be better off going for a different language - one with parallelism / multithreading built into its core architecture.

The first logical step after PHP is NodeJS, which has the fast iteration cycles of PHP without the low-level memory management or the enterprisey application server headaches of other languages, AND it has the advantages of a persistent service without needing to worry too much about parallelism because it's still single process.

But if you still need more performance you have a few options. But if you're at that point, you're already lucky. Most people wish they needed the performance or throughput of a language/environment like Go.

The execution model is definitely the biggest issue with PHP these days.

Although now that the PHP Foundation is officially supporting FrankenPHP maybe things will be evolving into a new paradigm.

https://thephp.foundation/blog/2025/05/15/frankenphp/

My hope is that the parallel extension will get more widespread adoption when its integrated into FrankenPHP: https://github.com/krakjoe/parallel

> 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.

Of course you haven't come across any such problem in PHP, because up until this point, if you had, you would have had to switch to another language to solve the problem that required the feature PHP didn't have.

There's an evaporative cooling effect on languages that don't have certain features where all the people who need those features leave after some number of years of not having them, leaving behind only the people who don't need them. There's a survivorship bias as a result.

I worked with dynamic scripting languages primarily for the first 15 years of my career but the definitive split for me was precisely when I had a problem they couldn't solve because they couldn't handle tens of thousands of simultaneous connections in any reasonable way.

This reply applies to all the commenters posting "but I've never needed this".

That doesn't mean PHP was useless without this feature, as it observably has solved a lot of problems. It just means that you shouldn't draw out too many conclusions from "I've never needed it", because you're still using it precisely because you're working in a space that doesn't need it, and your community is not constantly complaining about it because the people who would be complaining are no longer in your community. It means if you do develop a need for it in the future you won't have to leave PHP.

As a result this is a bad metric to measure the utility of a feature with.

On the flip side, it is valid to say "we've come this far without it and maybe we should be focusing on what we can do and continuing to invest in making that better rather than chasing the things we can't", especially since features like adding true threading add a lot of constraints to an implementation and make everything else you ever do in that implementation more expensive. Personally I am of the opinion that all of the dynamic scripting languages really need to just settle down, accept that they are what they are, and stop adding feature after feature after feature to 25-30 year-old languages.