About the Future of the TrueAsync Project

[EdmondDantes]

This week I began a round of outreach to the PHP community with the goal of promoting the project and raising awareness of it. I sent messages to key developers of frameworks, libraries, and components in order to hear their opinions.

And before you read the lines that follow, I would like to express my deepest gratitude to the people who have supported this project over the past two years. Many of them contributed to the RFC itself. I would also like to give special, separate recognition to YanGusik's work on adapting Laravel for asynchronous use: https://github.com/YanGusik/laravel-spawn. It was awesome!

Will the TrueAsync RFC be put to a vote within the coming year, or at least for PHP 8.7?

Answer: No, it will not. There is a 90% chance the RFC will not be accepted.

The main reason: the project has no support, not even at the level of its underlying philosophy.

Almost no one in the PHP community understands what it is for, or what the advantages of transparent asynchrony are. Unfortunately, people confuse TrueAsync with multithreading, or confuse TrueAsync with colored functions. This is true even of key figures in the PHP media space. It seems the RFC is not actually being read, or that it is written so poorly that the key points remain unclear. (Curiously, why doesn't AI run into problems like these?)

The current efforts to spread the word have not led to any meaningful success. On the marketing front, I have failed. This was a conscious choice, because I placed my bet on the quality of the product rather than on marketing, since marketing requires having a sufficient amount of resources.

The idea was that people would like a well-thought-out, coherent API that competing technologies don't have. That they would like not having to rewrite all of their code, but instead being able to use their existing codebases. Writing code sequentially, yet running it asynchronously. That, after all, is the Holy Grail: "It doesn't get any easier than this." But it turned out that implementing this idea was not enough. Something more is needed. And that something more is what I don't have.

The second reason. The large TrueAsync codebase written in C inspires dread, because there are no resources to review it. This is an objective problem, one that can be solved with funding. There is undeniably a cognitive dissonance here between "the language behind 70% of the internet" and "a language that has no money for asynchrony." And this concerns not even the code, but at the very least the RFC itself.

Unfortunately, the creation of a working group and the idea of an ambassadorship also fell through, for one reason or another.

Will the TrueAsync project be shut down?

Answer: The project will be carried through to version 1.0.0. This is planned, and it will be done.

At this point, work on the API is fully complete. Given that my company has recently moved to Python, the only thing left for me is to enjoy developing the PHP CLAW project on top of TrueAsync. Coding in pure PHP, with no threads, no processes, and no complex moving parts, just placing spawn on the right lines. I doubt there will ever be anything like it again.

P.S.

I do not consider this situation tragic. It is simply the reality of how things are. I ok with this.
PHP still has a chance to gain asynchronous capabilities, but I suspect they will take a different form and will likely always remain a second class citizen within the language.

[renji566]

so sad

[renji566]

The PHP language is destined to decline

[renji566]

Will you never participate in PHP coding again?

[EdmondDantes]

I am currently working on an MLIR-based JIT compiler for PHP.

[renji566]

OK

[renji566]

Have you recently heard about Swoole AOT, which is called TypePHP?

[EdmondDantes]

Have you recently heard about Swoole AOT, which is called TypePHP?

Yes, of course