https://tonybaloney.github.io/posts/why-isnt-python-async-more-popular.html
I would also recommend paying attention to an excellent article about asynchrony in Python and its problems. And next quotation: FastAPI, the web framework that’s async from-the-ground-up grew in popularity again from 29% to 38% share of the web frameworks for Python, taking the #1 spot. It has over 100-million downloads a month. Considering the big use-case for async is HTTP and network IO, having the #1 web framework be an async one is a sign of asyncio’s success. And this is despite the fact that there are various problems, such as code splitting due to colored functions. That’s a serious argument, isn’t it? чт, 22 янв. 2026 г., 17:15 Derick Rethans <[email protected]>: > On Thu, 22 Jan 2026, Edmond Dantes wrote: > > > > I don't like this experimental model or introducing API stability > > > levels as it is confusing for users. It requires extra checking for > > > users to do for each API (no one usually does it and with AI it will > > > be even more problematic because it might not tell that the > > > generated code uses experimental API). This would just become pain > > > for user and I don't think it would be good for PHP. > > > > I think this is a good topic for discussion, and we could talk about > > the pros and cons of a “nightly” build. I could explain how early > > product delivery improves code quality. > > > > > That can be already done but it will never guarantee that the second > > > vote will succeed. > > > It's OK! > > > > But at least I would know that the PHP community truly wants to make > > the language asynchronous. I still don’t understand the answer to that > > question. It seems to me: no. > > I think there is a difference between: > > 1. Make the PHP language wholly asynchronous > 2. Add some (more) asynchronous functionality to PHP > > From this series of RFCs, I think you believe that 1 is needed, or > perhaps *necessary*. On the other hand, I believe that most PHP > developers are more interested in the second option — run a few slow > things in parallel. > > There have now been more than half a dozen variants of the RFC, and > beyond the amount of work that you put in it, it also asks a lot of > everybody else to read and understand. > > As somebody earlier in these threads explained, the subject matter is > also not a simple one, and it requires deep understanding to be able to > understand all the trade-offs and consequences. > > Implementing this project requires is a large undertaking, akin to the > Unicode project (PHP 6). That project ultimiately failed because it > ended up being too big, with too many trade-offs. Your "True Async" > project additionally suffers from only having one main implementor. > > The Unicode issue got partly resolved by splitting it up into much > smaller blocks, in the form of the intl extension, and now in the last > few releases with better support for handling graphemes. We have seen > the same for PFAs and other langauge additions — this makes it much > easier to reason about that, and to get these features adopted. > > I have said this before, but for a large project like "True Async", you > really ought to get a group of people together in a Working Group, to > decide what *PHP users* would want this functionality for in a language > focussed mainly on web applications. > > But you approach this from the other side, by wanting to make PHP itself > an asynchronous language. I think doing such a large project, mainly by > yourself as the sole designed and developer, is doomed to fail. It isn't > something I would be confident about voting for, at least. > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: > https://xdebug.org/support > > mastodon: @[email protected] @[email protected]
