如何看待 swoole 团队反对 PHP fiber?

[sagaxu]

https://externals.io/message/113430

https://wiki.php.net/rfc/fibers

[weirdo]

元芳你怎么看

[yxx1993]

https://learnku.com/laravel/t/55115

[zhao372716335]

知乎这里有瓜： https://www.zhihu.com/question/448805077/answer/1777527343

[zhao372716335]

韩的确是个很牛 xx 的程序员，但是最近这几年的的骚操作，越来越像个商人，越来越不像个开源系程序员。

[zhao372716335]

Fiber 本质上赋予了 PHP 在用户态临时暂停任意函数调用的特技。如果配合外部事件调度框架（可以完全用 PHP 实现），就可以实现 swoole 的大多数功能。而且，更关键的点在于，PHP 社区现有庞在的类库几乎只做很少的改动就能适配到 fiber 上进而获得并发执行的能力。这跟 swoole 需要内置各种协程版类库形成了鲜明的对比。最后，因为 fiber 会合并到 php 内核，由官方背书。一旦投票通过，会得到整个社区的支持。届时，swoole 就会被逐步边缘化。所以，swoole 相关的人就开始反对了。关于反对的内容，建议大家直接看原始讨论邮件，不要相信一家之言

[sorshion]

最新解释在这儿： https://zhuanlan.zhihu.com/p/356942841

swoole 在几次事件中的表现，确实令我挺失望的。

本身提出的几点我觉得确实是有道理的

1. 从用户角度更希望一步到位的解决方案
2. fiber 不完整，后续 event loop 的实现，各家各异，确实一定程度上会造成内卷，哪怕经过厮杀，php 到时候早已热度不再

[sagaxu]

@sorshion 6# 我觉得 rfc 解决的是语言特性，一步到位是框架和库的职责，我们不能因为用户主要用 orm 就否认 pdo 的价值吧，当 fiber 成为语言特性时，好处是显而易见的，

第一，衍生出各种基于 fiber 的框架。
第二，现有的库会考虑支持 fiber 。

实践一段时间之后，会有那么一两个比较好的 eventloop 和调度器方案成为事实标准，然后跟 fiber 一样进入 PHP 核心。分阶段一步一步来，等 php9 出来的时候，php 协程方案可能就成熟了。

fiber 其实有点类似 kotlin 的 coroutine，两类代码需要 bridge 粘合起来，不如 go 那般顺滑，但对一个有 20 多年包袱的成熟生态来说，也许是比一刀切更好的选择。

当然对 Swoole 不是什么好事，标准的主导权丧失了，英文文档和社区也拼不过，前景不容乐观。

[sorshion]

@sagaxu 我担心，它成熟前，更多的 phper 选择了离开

[sagaxu]

@sorshion 别担心，phper 转 Go 转 Java 是既成事实了，不会因为 fibers 或 swoole 有多大改变

[zhao372716335]

@sagaxu 你还是太年轻了，你看看 php 的排榜吧

黑 php，唱衰 php 的，得十几年了

PHP 虚脱过吗？排名一值很坚挺。

[mrpzx001]

2 年了，fiber 玩出什么花了吗？