令人惋惜!PHP True Async RFC 投票没有通过

PHP社区传来一个令人惋惜的消息，True Async RFC 1.6版本的投票已经结束，最终未能获得通过。这对于期待PHP原生支持异步编程的开发者来说，无疑是一个沉重的打击。

一场仓促的投票

回顾这次投票过程，可谓一波三折。RFC的作者Edmond Dantes于11月19日宣布开启投票，但却没有按照惯例将投票组件放在RFC页面上，这一不同寻常的操作立刻引发了社区成员的质疑。

Derick Rethans直接发问：“为什么投票组件不在它本该在的RFC页面上？”Matteo Beccati也表示在投票尚未正式开始时就收到[VOTE]邮件实在“奇怪”。

更令人担忧的是，投票开始后不久，Jakub Zelenka指出由于PHP政策在11月20日发生了变化，这次投票恰好卡在了政策变更的节点上。虽然最终认定投票有效，但作者只有三天时间来决定是否停止投票。

为什么社区对此反应强烈？

True Async RFC的核心目标是让PHP能够原生支持并发编程，而不依赖于诸如Swoole、AMPHP、ReactPHP等第三方扩展或框架。

该RFC提出了一个隐式模型，让开发者能够直接用同步的代码风格编写异步程序，最小化代码修改和语法变化。

想象一下，未来你可能不需要重写现有代码，就能让PHP程序同时处理多个请求，就像Go语言的协程那样。这对于PHP在高并发场景下的应用将是一次革命性的提升。

深层次原因：过程重于结果

从讨论来看，投票未通过的原因并非完全因为技术问题本身。

Rowan Tommins敏锐地发现了一个矛盾：在投票开始前两天，RFC作者还同意Bart Vanhoutte的观点，认为需要组建工作组、让框架代表参与、让库有提前适配的能力，这才是开发此类特性的唯一有效过程。

然而仅仅两天后，作者就结束了讨论并开启了投票。这种匆忙的进程让社区感到不安。

Tim Düsterhus在讨论中提到，虽然投票本身有效，但投票取消则需要遵循新政策。这在一定程度上反映了PHP社区治理机制的演变。

专家意见缺失的讨论

Bart Vanhoutte曾指出一个关键问题：虽然社区中有许多开发异步库或扩展的专家，但他们几乎都没有参与这个RFC的讨论。

对于一个会彻底改变我们开发方式的RFC，没有相关领域专家的深度参与，讨论质量难以保证。

Daniil Gentili则从另一个角度表达了担忧：PHP社区整体对异步编程还比较陌生，导致讨论陷入了“颜色理论”的争论，而缺乏实际经验的支撑。

历史的教训

这并非是PHP社区第一次因讨论不足而否决重要特性。Stanislav Malyshev曾在2015年表达过类似的失望：当时有20人投票反对某个RFC，但只有约1/5的人参与了最低限度的讨论。

健康的RFC流程需要反对者至少简要解释他们的顾虑，而不是简单投下反对票。

True Async的未来

尽管这次投票没有通过，但True Async的理念已经引起了广泛共鸣。根据新政策，如果RFC未能通过，六个月内不能重新提出，除非有重大修改。

从积极的一面看，True Async的一些实验性工作已经在进行中，包括与NGINX Unit的集成，展示了单个PHP进程同时处理多个请求的可能性。

启示与展望

这次True Async RFC的失败，给我们留下了深刻的思考：

技术决策需要时间与共识。特别是对于可能改变整个语言生态的特性，仓促推进反而会适得其反。

社区治理需要平衡。如何在效率与包容性、专家意见与社区共识之间找到平衡点，是每个开源项目都要面对的挑战。

沟通与过程至关重要。即使技术方案再优秀，如果缺乏充分的沟通和透明的过程，也难以获得社区支持。

True Async的理念无疑代表了PHP进化的方向，但技术有时快一点，社区有时慢一点，这次虽然遗憾，但也许不是终点。让我们期待改进后的提案在未来能重新出发，赢得更广泛的共识。

PHP的未来，终究还是掌握在每一个关心它、使用它、为它贡献的人手中。