Hello, Thank you a lot.
> Swoole’s aim is to leverage PHP’s existing ecosystem rather than build a new > one. If we were > starting from scratch—discarding PHP’s commonly used functions and learning > an entirely new > async API—why wouldn’t developers simply switch languages? And it turned out to be a very successful solution, which has been proven many times in practice. The first question developers ask when they want to migrate to async is: how much code do I need to rewrite? If the cost of migration is comparable to rewriting the entire project from scratch, then it becomes economically more sensible to hire Go developers and rebuild the project. And PHP’s influence is strong primarily because of the companies that run PHP-based projects. So when a company decides to rewrite a project in another language because PHP no longer meets its technical needs, PHP loses that client. That’s why supporting a single runtime and a single API, standardization, is crucial for the technology’s survival. Those were the economic reasons. There are technical reasons as well. In a server that handles multiple requests within a single thread, it is very important that coroutines do not occupy the CPU for too long. If they do, all coroutines in that process are affected. This means that having blocking operations inside a coroutine nullifies the advantages of concurrency. Therefore, intentionally making functions blocking so that code works correctly with shared memory makes the idea of using asynchronous code **pointless**. This does not mean that one solution or another is 100 percent perfect. Each has its drawbacks. The question is whether the drawbacks outweigh the benefits. Swoole made it possible to see that, in practice, using a unified API provides a significant advantage that makes migrating legacy projects feasible. This means that by voting for an RFC built on these principles, we are not venturing into a dark unknown, but walking along a well-trodden path. ---- Ed
