🗳️ [Letter] An Open Letter to the PHP Development Team and Core Community Members

[Tinywan]

An Open Letter to the PHP Development Team and Core Community Members

Dear PHP Development Team and Core Community Members:

Hello everyone! I am Tinywan, an ordinary PHP developer. Today, I am writing this letter to you with mixed feelings: both infinite gratitude for PHP and deep concern for its future.

• GitHub: https://github.com/Tinywan
• Open Collective: https://opencollective.com/tinywan/transactions

My Original Intention: Gratitude and Contribution

Like many developers, PHP has transformed my career. From the initial bewilderment upon first contact to now proficiently using it to solve complex problems, it is PHP that has shaped who I am today. Because of this "never forget the original intention" gratitude, I have always hoped to do something for this language that has accompanied my growth.

Therefore, I am not just a user of PHP but strive to be a contributor. I am honored to be a member of the PHP Foundation, providing financial support to the best of my ability, as I deeply understand the importance of the Foundation in ensuring the longevity and prosperity of the PHP language. At the same time, I run my personal tech WeChat public account "Open Source Tech Stack," dedicated to sharing PHP technologies and promoting the PHP ecosystem, in hopes of attracting more people to learn about and fall in love with this language. Every time I see a newcomer getting started with PHP because of my articles, I feel immense joy.

My Concerns

However, as I promote PHP with full enthusiasm, I increasingly feel a sense of powerlessness. This sense of powerlessness reaches its peak in the field of "asynchronous programming."

As discussed in the community, PHP's asynchronous ecosystem is caught in a "three-way battle": excellent projects like Swoole, Workerman, and AmpPHP are each fighting on their own, with different underlying implementations and incompatible APIs. This brings a fatal problem: How do we introduce PHP's asynchronous development to newcomers?

When I encourage newcomers to learn high-performance programming, I cannot provide a clear, unified path. I have to tell them that they need to first choose a "camp," learning "PHP + Swoole" or "PHP + Amp." This undoubtedly raises the "low threshold" advantage that should belong to PHP, making many beginners feel confused and intimidated right from the start. As a promoter of PHP, this pains me deeply. We work hard to attract fresh blood to PHP, but the ecosystem's fragmentation may unknowingly deter them.

My Plea: It Can Be Unused, But It Cannot Be Absent

We have noted that the long-awaited "true_async" (coroutines) RFC in the community recently failed to pass the vote. We understand the team's caution regarding language complexity, but as a contributor who deeply loves PHP, I want to emphasize a simple principle: Some features can be unused, but they cannot be absent.

RFC: https://wiki.php.net/rfc/true_async

Native coroutine support is exactly such a "cannot be absent" feature. It is not about forcing all developers to write asynchronous code, but about providing the entire ecosystem with an official, standard, unified underlying capability. It is like laying unified "plumbing and electrical infrastructure" for the PHP building; as for whether to install chandeliers or desk lamps in the rooms, that's up to the developers to decide.

With this underlying primitive, frameworks like Swoole, Workerman, and AmpPHP can gradually unify standards, allowing library authors to achieve "write once, run everywhere." Refusing to provide native support is tantamount to completely "outsourcing" this most fundamental problem to the community, allowing fragmentation to intensify. This may seem to preserve the "purity" of the language core, but in reality, it sacrifices the language's future development potential and the ecosystem's cohesion.

My Expectations: A Stronger, More Unified PHP

The reason I am so anxious is precisely because I deeply love PHP and have invested my time and effort into it. I do not want to see it gradually lose competitiveness due to hesitation on key features.

Here, I earnestly appeal to the official PHP team:

1. Re-examine and prioritize the introduction of native coroutine support into PHP. This will be the most critical step in ending the "three-way battle" in the asynchronous ecosystem and unifying the community.
2. Engage in deeper, more open communication with the community (especially core developers of projects like Swoole, Workerman, and AmpPHP). Together, explore a solution that maintains PHP's style while meeting future needs.

A unified, built-in asynchronous solution will greatly reduce the learning cost for newcomers, consolidate community strength, and give promoters like me more confidence to attract the next generation of developers. More importantly, it will allow PHP to continue shining on the stage of modern software engineering.

Thank you once again for your hard work. I look forward to a stronger, more modern PHP!

Sincerely, A Loyal PHP Developer and Contributor . Tinywan

Link

• https://www.workerman.net/a/1746

[AllenJB]

We have noted that the long-awaited "true_async" (coroutines) RFC in the community recently failed to pass the vote. We understand the team's caution regarding language complexity, but as a contributor who deeply loves PHP, I want to emphasize a simple principle: Some features can be unused, but they cannot be absent.

RFC: https://wiki.php.net/rfc/true_async

This RFC has not yet been voted on. It's still undergoing discussion on the internals mailing list. You can find the latest discussion thread here: https://externals.io/message/129004

You can find previous discussions in the References section of the RFC (or search for "true_async" on externals.io or other list archives)

Anyone can subscribe to the internals mailing list and join discussions. It's not restricted. PHP projects and individual developers with an interest in features such as async are encouraged to subscribe and contribute to discussions.

For official archives and subscribe instructions, see https://www.php.net/mailing-lists.php

Note that this repository is likely not monitored by the majority of PHP internals developers. The best place to contribute to be heard is the internals mailing list.

As a long-time user of ReactPHP and other async libraries, I am hopeful for this RFC. But it's important that what gets into core PHP is done right as once it's released, it becomes significantly difficult to correct issues, and the wrong implementation could potentially block better alternatives while getting in the way of users.

[sy-records]

Yes, the correct approach is to use the mailing list, not to file an issue in this repository.