Good morning from a rather cold but sunny Belgium, About Backwards compatibility & colored functions.
Right now, I think there's a problem with the promise of backward compatibility. Unless your application handles shared state perfectly, switching on async PHP is going to cause a lot of problems. Ignoring the problem and asking users to rewrite shared state in their applications is an absolute no-go from me. On the other hand, we could go down the path of colored functions, which is also an absolute no-go from me. We've had this in the past before Fibers were a thing and it was an absolute pain in the ass. Every function only accepted Promise<x> and only returned Promise<x>. Bear in mind this coincided with the rise of static typing and FIG-PSRs where you could get away with it until Interfaces accepted and returned actual types. Having colored functions could mean having to duplicate all interfaces where you would have sync and async ones. This would split the ecosystem in two and kill adoption, no thanks. I would much rather have some solution where we can enable (opt-in) non-blocking/async behavior on a per-project basis. At the very least we'll be able to use it in greenfields projects. Developers who want to add support for non-blocking/async I/O in their existing applications can then rewrite their global state and turn it on whenever they feel ready for it. It's not ideal but I think it's a nice compromise between fast adoption and backward compatibility. I envision a time where you'd look at the documentation of a library and see "ok, this is async-ready" (shared state is dealt with) through some badge or something. --- For people who are questioning whether a feature like this should be added to PHP I'd like to point out a couple of things. 1. Current usage of async PHP is not a good argument. Like I've previously said elsewhere, this is a classical chicken-or-egg thing. Some people think it's not worth adding support for this because nobody is using it but also very few people are using async PHP because it's not a first class citizen in the language. Having a couple of libraries and frameworks supporting whatever async model PHP ends up choosing would increase these numbers drastically. Adding support for this new paradigm in popular frameworks/CMSes and thereby pushing the language and ecosystem forward seems like something the PHP Foundation was founded for (wrong mailing list, I know). 2. About handing off the problem to Userland: you can _kinda_ do things asynchronously in PHP through Userland (I'm talking Fibers) these days, but having async as a first class citizen in PHP core would make things much easier. Currently, the ecosystem is fragmented and you need a lot of libraries and specific knowledge in order to get started. We've been doing this for a couple of years now and only recently we got a decent ORM to work async (one unit of work per Fiber, transactions, ...). 3. I think PHP is especially suited for this paradigm. Web applications require a lot of I/O, whether it is talking to the client, database, filesystem, API's, ... Having the ability to either serve multiple requests at the same time through a long running process or - for example - upload a file to S3 and concurrently write a record registering that file in the database can lower the TTFB of web applications drastically. Moreover, as shared hosting is a thing, spawning more processes or threads isn't always going to be available. I feel like not adding async to PHP in the (near?) future would only be postponing it and risk developers looking to squeeze that extra bit of performance from their applications to _Go_ to other languages. --- On a final note, it's nice to see this discussion is gaining some traction! I've just checked with core ReactPHP developers and they're checking up on the RFC, however, their main concern seems to be the same as others on this list: time. Everything is changing very fast and more time is needed to digest this all and to get used to the idea of this mentally. I agree with others, this is something that we have to do right, so let's take the time to do it right. There's already been an awesome effort by Edmund, let's keep working on this. Best Regards, Bart Vanhoutte Op vr 21 nov 2025 om 13:08 schreef Edmond Dantes <[email protected]>: > > Hello > > > I think you seriously underestimate impact of this in the current PHP code > > bases where many applications depend on global state. > Do I really look like someone who could underestimate memory-related issues? > :) > > > Now imagine that some popular plugin decides to use async which change some > > of its globals (like $post or $wp_query) during the suspension of the main > > code. I would assume this could horribly break things. > Or for example, you run an old WordPress on the new PHP 8.5 and > everything breaks. Is that a reason not to release new PHP versions? > No, I’m not joking. That’s literally the essence of the argument. If > something might break, then we shouldn’t do it? > > This is a common story. There is a framework that is adapted to a > technology, and there is a framework or library that is not adapted to > it. > If a framework is not adapted, you simply won’t be able to use the > technology. So why is this considered a problem? > However, inside WordPress you will still be able to use coroutines as > long as you don’t call WP functions that aren’t adapted. You can. So > why is this a problem? > > I can use AMPHP inside WordPress and break WP. > So does that mean we must urgently remove Fiber from the language? > Because AMPHP uses Fiber, and AMPHP implements coroutines. And > coroutines break WordPress. > Asynchrony already exists in PHP. You can write async code today. > Which means you can already do all the “horrors” you’re talking about. > TrueAsync cannot change that. And no one else can change it either. > So why is this being treated as an argument against it? > > > Don't forget that other code don't have control over the plugin and it > > might not even know that async is used there. > Exactly. This means that right now I can use Fiber plus select() to > write async code and break WordPress. > And I can also write a plugin that divides by zero and crashes > WordPress, and WordPress won’t know anything about it. > > > So I'm not sure if this design is compatible with WordPress > > Yes, WordPress is not compatible with asynchrony. I’ll emphasize > again. This is not about TrueAsync specifically. This is about > asynchrony itself. Yes, WordPress and Laravel are not compatible with > concurrent execution. That’s true. > But are you **really suggesting** that because of this, all other > applications should be denied the ability to use it? > Moreover, would you deny WordPress itself the possibility of > supporting asynchrony in future? After all, WordPress can be > refactored. It’s not carved in stone. > > Wouldn’t WordPress benefit from the performance improvements that > async provides? > Wouldn’t WordPress plugins benefit from being able to actively > communicate with microservices and deliver the fastest possible > responses to JavaScript? > > Is this feature really something nobody needs? If yes, then I have no > further questions. > > Async is needed to increase throughput. That’s the purpose. If a PHP > project doesn’t need it, it doesn’t have to use it. That’s fine. But > there are PHP projects that do need it.
