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
