Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Coroutines in PHP

doeken.org

Post reply on HN
Print view View original

21–30 of 68 posts

Re: Exploring Coroutines in PHP

#21

Post by Pesthuf »

donatj wrote: post #7

I have read much about Fibers since they were introduced and have never come up with a real use case. All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as…

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.

Re: Exploring Coroutines in PHP

#22

Post by pier25 »

pachico wrote: post #4

I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.

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/

Re: Exploring Coroutines in PHP

#23

Post by danogentili »

donatj wrote: post #7

I have read much about Fibers since they were introduced and have never come up with a real use case. All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as…

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.

Re: Exploring Coroutines in PHP

#24

Post by hibikir »

donatj wrote: post #7

I have read much about Fibers since they were introduced and have never come up with a real use case. All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as…

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

Re: Exploring Coroutines in PHP

#25

Post by todotask2 »

pier25 wrote: post #22
pachico wrote: post #4

I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.

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/

There was a long discussion recently on FrankenPHP.

https://www.reddit.com/r/PHP/comments/1lqpkfq/frankenphp_any...

Re: Exploring Coroutines in PHP

#26

Post by jerf »

philo23 wrote: post #19

Personally I've never come across any problem in PHP that I feel like Fibers would help me solve. Having Fibers in PHP is a nice addition but it definitely feels more like plumbing for other PHP extensions/frameworks to use, rather than something the average dev would use themselves directly day to day.

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.

Re: Exploring Coroutines in PHP

#27

Post by bvrmn »

Cyykratahk wrote: post #15
Amakanski wrote: post #3

>> This would require a yield to syntax, which doesn't exist. There is however the 'yield from' statement.

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

PHP generators/iterators is a hot mess. I don't know any other language which forces iterators to output a key for `foreach(... as $key => ...)`.

Re: Exploring Coroutines in PHP

#28

Post by saghm »

Cthulhu_ wrote: post #17
pachico wrote: post #4

I don't write PHP code anymore. I had a great time doing so for years but now I mostly write in Go for a company that writes a lot in PHP. What I see from PHP is a missed opportunity for not having any native lightweight multi thread capabilities not a robust HTTP server. I wish the situation changed.

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 witho…

By this logic, it seems like it would make more sense to just start with Node rather than PHP for the prototype and save the potential rewrite. Node does seem more popular than PHP nowadays to me as an outsider to both, so maybe that's exactly what did happen.

Re: Exploring Coroutines in PHP

#29

Post by donatj »

danogentili wrote: post #23
donatj wrote: post #7

I have read much about Fibers since they were introduced and have never come up with a real use case. All the examples I find are like the trivial ones here where it just feels like instead of jamming a bunch of code into a single messy function that yields, you'd be better off particularly from a static analysis standpoint just having ordered method calls or chained callables where each step returns the next step as…

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.

A fiber is a colored function. It's a different color than an async function, but it's not blindly swapable for a regular function.

Re: Exploring Coroutines in PHP

#30

Post by jw1224 »

bvrmn wrote: post #27
Cyykratahk wrote: post #15

Earlier quoted context omitted.

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

PHP generators/iterators is a hot mess. I don't know any other language which forces iterators to output a key for `foreach(... as $key => ...)`.

PHP doesn’t force keys... You can omit the key and simply write `foreach($items as $value)`
Post reply on HN