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

31–40 of 68 posts

Re: Exploring Coroutines in PHP

#31

Post by [deleted] »

djxfade wrote: post #16
zelphirkalt wrote: post #11

Earlier quoted context omitted.

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…

That's not totally correct. PHP has a "short function" syntax for that specific use case, it automatically captures data without the 'use' statement. $a = 5; $b = fn ($c) => $a * $b; print($b(2)); // 10 print($b(4)); // 20

[deleted]

Re: Exploring Coroutines in PHP

#32

Post by doekenorg »

Amakanski wrote: post #3

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

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.

Re: Exploring Coroutines in PHP

#33

Post by sroussey »

ckbkr10 wrote: post #12
zelphirkalt wrote: post #10

Earlier quoted context omitted.

That's in no way lightweight though, and most languages can easily do the same. Just launch multiple instances/VMs/processes. That's having multiple separate OS processes, each having everything that is needed to run PHP, and having no way to communicate with each other, other than what you implement. No channels, no task distribution, no queue on which to sync and take tasks from, no signaling of all processes being…

PHP is not about lightweight, it's about rapid development. A lot of implementations in PHP are dead simple and can be debugged even by beginners. You generally do not implement efficient systems in php, they are easy to debug, fast to code and quick to fix though.

Most of the time you don’t really need to think about memory management either as the memory for the process is simply reset on every request.

Re: Exploring Coroutines in PHP

#34

Post by doekenorg »

Just to clarify my intent with posts like this:

I'm not suggesting that PHP is the ideal tool for every use case. The goal is to share a concept that might be unfamiliar to some developers, using PHP as the context.

Sometimes learning about a concept in a familiar language helps you recognise where it might be useful elsewhere or apply it in a language that supports it better.

Terms like coroutines, concurrency, promises, etc, can be confusing; I just like to demystify them with easy-to-grasp examples. That does mean that examples can be contrived or very simple, but they are designed to get the point across.

Thanks for all the comments so far!

Re: Exploring Coroutines in PHP

#35

Post by tored »

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/

But why pick PHP then? Why not use nodejs or similar where the language, application stack and the community is already in agreement on the execution model.

Re: Exploring Coroutines in PHP

#36

Post by pier25 »

tored wrote: post #35
pier25 wrote: post #22

Earlier quoted context omitted.

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/

But why pick PHP then? Why not use nodejs or similar where the language, application stack and the community is already in agreement on the execution model.

I don’t use php but it’s extremely popular around the world. There’s also Laravel which seems a lot more productive than anything in js for full stack dev.

Re: Exploring Coroutines in PHP

#37

Post by mschuster91 »

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…

> The first logical step after PHP is NodeJS, which has the fast iteration cycles of PHP

... not really, you still have to deal with bundlers in real-world applications.

Re: Exploring Coroutines in PHP

#38

Post by supriyo-biswas »

doekenorg wrote: post #34

Just to clarify my intent with posts like this: I'm not suggesting that PHP is the ideal tool for every use case. The goal is to share a concept that might be unfamiliar to some developers, using PHP as the context. Sometimes learning about a concept in a familiar language helps you recognise where it might be useful elsewhere or apply it in a language that supports it better. Terms like coroutines, concurrency, prom…

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!

Re: Exploring Coroutines in PHP

#39

Post by 9rx »

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…

> Most people wish they needed the performance or throughput of a language/environment like Go.

Most people do need the performance and throughput offered by modern languages like Go, though. Time to market is the most important consideration for most. Maybe at Facebook scale you can spend eons crafting perfection in a slow-to-develop language/ecosystem like PHP or NodeJS, but most people have to get something out the door ASAP.

Re: Exploring Coroutines in PHP

#40

Post by alganet »

cardanome wrote: post #6
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.

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.

The shared-nothing architecture is great for some scenarios.

Long running processes and async I/O are a great tool to have though. They are present in PHP for almost two decades now, and despite having many incarnations (select(), libevent, etc) and even frameworks (amp, reactphp, etc) the knowledge is highly transferrable between them if you understand the fundamentals.

Post reply on HN