> Edmond Dantes <[email protected]> hat am 22.11.2025 05:17 CET geschrieben: > > > Hello > > > from userland perspective I would prefer explicit declaration on each usage > > of async over declare(), hooks and INI. This would make reviews, static > > code analysis, etc. easier. > > RFCs can be written in small parts for each new function, e.g. > > This solution has the following consequences. > > We have a REST API project that is 10 years old. Recently we learned > that PHP 9 has been released, and we can improve performance. To do > this, we need to: > 1. Migrate to another web server. > 2. Wrap the request-handling code in a coroutine. > > However, it turns out this doesn’t work. If the code inside the > coroutine doesn’t yield control, then there is no improvement at all. > And we’re like… this technology is useless. > > And then one of the developers says: “Guys, we just need to rename all > functions to _async and it will work.” > (And he’s this young optimistic perfectionist programmer who says: > *“Then the code will be beautiful, amazing, and blaaaaaazing!”*) > > Everyone happily writes a script to rename 30-50,000 lines of a > many-years-old project. New bugs appear. But we fix them, hoping for a > better future. > And then it turns out that after renaming the functions nothing works, > because shared memory has to be removed. > > In other words, the team spent time on refactoring, and in the end > they still had to do the refactoring that was unavoidable. > > What benefits did the developers gain? > 1. Did the code become clearer? Yes, the code became a bit clearer. > It’s visible that the functions will yield control. > 2. Did the number of bugs decrease? > 3. Did the amount of code changes become smaller? > 4. Did API segmentation appear? > > People won’t rewrite code unless the business is at risk. And even > then, very often no one does anything. Therefore, the **more** > complicated the transition to asynchrony is, the **less likely** it is > to ever happen. > There is a chance that asynchrony could give the language a push > toward greater memory safety and make it more functional in style. > Because features in programming evolve according to the law of > accessibility. The more accessible a feature is, the more likely it is > to be used, and the more widespread it becomes. Go made parallel > programming more common because it made it simpler. > > --- > Ed
Maybe misunderstanding, I'm not proposing coroutines, I'm proposing to add new functions for async io. e.g. // currently we have $content = \file_get_contents(); // old function remains: sync, returns string|false // new function file_get_contents_async $promise = \file_get_contents_async(); // new function: async, returns a promise object (similar to node.js using fs.readFile and fs.readFileSync) Regarding 10 year old projects: I would only add new functions and don't change existing functions for async io. So new async functions can be used, but don't need to be used. I expect that's already a good improvement for many use cases to read multiple files in parallel, run multiple queries in parallel, etc. Best Regards Thomas
