PHP社区的一个好消息和一个坏消息

继续用swoole/swow

基本通不过的，不用指望社区了，那帮人只会抱着FPM修修补补，看看PHP8就知道了

作者基本心灰意冷了，几批人完全不在同一个频道上，都聊不到一块去

通不过的，都老思想了

很难了，这些php老古董真是害死了PHP

才一票通过，基本没戏了

最终结果也只是1票通过，其他要么反对，要么弃权；这里面有个细节就是作者希望在php8.6+版本落地trueAsync，我琢磨那帮人并不希望php8.x版本加这么大调整，兴许php9版会有这么个玩意，不过怎么折腾，也难抵php日渐式微，因为他们总是滞后于时代，慢慢被时代所淘汰。

用ai 看了一下第5次的讨论内容。 externals.io/message/129004

根据您提供的邮件列表讨论内容，这个RFC尚未进行投票，因此没有投票结果。 讨论显示，原计划在2025年11月底进行的投票被推迟了，主要原因如下： 核心问题与投票推迟的原因 与现有 Fiber API 的根本性冲突 问题：True Async 提案与 PHP 现有的 Fiber（纤程）API 不兼容，两者无法共存。True Async 提供的是不对称协程（由调度器自动管理切换），而 Fiber 是对称协程（需要开发者手动控制切换）。 争议：一些参与者（如 Dennis Birkholz）认为，应该增强现有的 Fiber API 来满足异步需求，而不是引入一套全新的、不兼容的体系。他们认为这避免了生态碎片化。 反驳：RFC 作者 Edmond 认为，Fiber 是过于底层的原语，将其改造为高级的、自动调度的协程既困难又低效，违反了“严格分层”的软件架构原则。他认为 True Async 和 Fiber 解决的是不同层次的问题。 关键设计细节不清晰，引发广泛担忧 “透明异步”的承诺与潜在风险：RFC 宣称目标是现有同步代码无需修改就能在协程中运行。但参与者（如 Rob, John, Larry Garfield）指出，隐式挂起​ 会引入难以调试的并发 Bug（如竞态条件、数据竞争）。 示例：如果一个协程在读取并修改一个共享对象的属性过程中被挂起，另一个协outine可能在此期间修改了同一对象，导致数据不一致。 核心争议：这是最大的分歧点。反对者认为必须有显式标记（“着色函数”，即 async/await 关键字）​ 来明确指出代码中可能挂起的地方，否则对开发者来说代码行为将不可预测。而 RFC 作者认为，PHP 应该效仿 Go 语言的模型，挂起点是实现细节，开发者不应依赖。 实现策略和审查难度 问题：参与者（如 Jakub Zelenka）反复强调，需要一个最小化、可审查的实现​ 来配合 RFC。他们希望先合并一个最核心的协程机制，然后再逐步添加非阻塞 I/O 等功能。 现状：虽然 Edmond 有一个功能完整的实现，但它包含了大量内容（如基于 libUV 的 Reactor、非阻塞的标准函数改造），导致代码库庞大，难以被核心开发者全面审查。 社区认知与沟通挑战 认知差距：正如 Marco Deleu 和 Bart Vanhoutte 指出的，这是一个“范式转变”级别的提案，但大多数 PHP 开发者没有异步编程的经验。RFC 的复杂性和密度使得许多投票者难以理解其全部含义。 沟通负担：讨论中，作者 Edmond 与参与者之间出现了一些沟通不畅。一些参与者感觉他们的基础问题被忽视，而作者则觉得讨论没有向解决具体细节的方向推进。

几个大版本的更新 并没有为php带来任何现代化的变化 老古董门好气人