PHP 原生异步 TrueAsync 项目的未来

我还要特别、单独感谢 YanGusik 在将 #Laravel 改造成异步使用方面的贡献：https://github.com/YanGusik/laravel-spawn。这非常棒！

TrueAsync RFC 将在未来一年内或至少在 PHP 8.7 中被投票通过吗？

回答：不会。它将不会通过。有 90% 的概率 RFC 不会被接受。

主要原因：该项目没有支持，甚至连其基本哲学都不被支持。

几乎没有 PHP 社区的人理解它的目的是什么，或者透明异步的优点是什么。不幸的是，人们会把 TrueAsync 和多线程混淆，或者把 TrueAsync 和彩色函数混淆。这甚至在 PHP 媒体空间的关键人物中也是如此。看起来 RFC 实际上没有被阅读，或者写得太差以至于关键点仍然不清晰。（有意思的是，为什么 AI 不会遇到这些问题？）

目前传播努力没有带来任何有意义的结果。在营销方面，我失败了。这是我的有意识选择，因为我把赌注押在产品的质量上，而不是营销上，因为营销需要足够多的资源。

本以为人们会喜欢一个经过深思熟虑、连贯的 API，而竞争技术没有这样的东西。他们会喜欢不用重写所有代码，而是能够使用现有代码库。以顺序方式编写代码，却异步运行它。这毕竟是圣杯：“这已经再简单不过了。”但事实证明，实现这个想法是不够的。还需要一些东西。而我没有那个“一些东西”。

第二个原因。使用 C 语言编写的巨大 TrueAsync 代码库会让人望而生畏，因为没有资源来审查它。这是一个客观问题，可以通过资助来解决。这在“互联网背后 70% 的语言”和“没有资金支持异步的语言”之间不可否认地存在认知失调。这甚至不是关于代码本身，而是至少关于 RFC 本身。

不幸的是，创建工作组的想法和大使计划也失败了，无论是出于什么原因。

TrueAsync 项目会被关闭吗？

回答：项目将一直执行到版本 1.0.0。这是计划好的，会完成的。

目前，API 的工作已完全完成。鉴于我的公司最近转向 Python，我唯一要做的就是享受在 TrueAsync 之上开发 PHP CLAW 项目的乐趣。用纯 PHP 编码，没有线程、没有进程、没有复杂的移动部分，只是把 spawn 放在正确的行上。我怀疑以后再也不会有像它这样的东西了。

附言：我并不认为这种情况是悲剧。它只是事情的现实。我接受了。PHP 仍有获得异步能力的机会，但我怀疑它们会以不同的形式出现，并且很可能永远在语言中保持二等公民地位。