才看到 PHP 协程扩展 Swoole 去年的时候发生的分支事故

看那作者 应该是可以约见的事

@terranboy 预见

这个框架故事太多

没有必要，换 Go 就行，时代在发展，该淘汰还是要淘汰。

在我的印象里都好像是老早之前的事了。PHP 怎么说呢，实用为主，你说的这个事跟 PHP 其实关系不大，类似这种库发展起来还是相对有限，生态方面不是一个 Swoole 的问题。历史包袱，领域受限，早年的设计问题
... 但所有老语言为了保持兼容也都有各种历史包袱，推陈出新也不奇怪。

以社区驱动的 PHP 还是在不断的变好的，但也很难在其他赛道超车了。我也是 PHP 基金会的捐助者，PHp 基金会最直接的目的是为了帮助 PHP 内核开发者，短期肯定是见不到啥成效，未来 ... 未来可期吧

At this stage, all the member's releases have to use matyhtf's PECL account which is ridiculous for a project contributed by a group of people.

我很震惊难道在此之前是几乎没有（以 21 年 18 次的发布次数来看，我心中的几乎没有指的是一次或更少）其他成员去执行发布这个操作吗？如果有的话，居然没有人提出过异议吗？还是说只是也被忽略了？（但哪怕没人提过，我也认为作为唯一的 lead ，韩应该意识到这是个问题并且给自己找一个 backup （于是我去翻了翻 contributor ，更震惊的发现了如果我是韩，我也选不出一个 backup 来））


再回到这次事情的起因上，我也是强烈反对在 core 里边加上一个对外部网站的依赖，无论那个网站是否是商业性质的（而且刚才试了试 business.swoole.com 这个域名还直接因为没备案给 block 了？）。然后 Bruce 指责韩尽管承诺解决，但直到 fork 前都没有实质行动，那个总结的 comment 中并没有提及 introduce 这个 change 的 commit ，所以我去挖了一下，https://github.com/swoole/swoole-src/commit/73372ad07720f3f024d8b86b50d2e96dc9b6c1de 。从 8 号提交，到 14 号（冲突后）删除，其实只有 6 天，尽管是 master 分支，但考虑到没 release 其实我觉得这个时间并不算久。但还是有两个我觉得有问题的点，第一个是刚才发的这个引入这段代码的 commit ，commit message （ Added tests, improved server stats_file, fix core-tests ）中完全没有提及这一点，甚至可以说是将本应是好几个 commit 的文件放到了一个里来提交，至少让我觉得有点想浑水摸鱼。第二个是在 14 号就直接 release 了新版，我也很好奇如果这场撕逼不发生，这段代码是不是就顺势 release 了？


至于对 php 未来的看法，船大难掉头吧。现在的新版更多的是各种语法糖和小修小补，大的一些变更（比如异步 IO ）之类的应该是有生之年都没希望了（这种大的变更 php-internal 时不时都会冒出来相关的讨论，但有一些特性我已经成功地被说服成不要添加那一派了）。web 开发基本上也是小的网站用啥都行，大的也轮不到动态语言。php 应付中小型的网站已经绰绰有余了。

@jhdxr 感觉就是发布版本时候没有利用 review 机制监督，再加上发布 pecl 帐号共用的事情，感觉管理得不是很好，Swoole 本来应该做得更好的。

@jhdxr 这句话是说其他成员发布的时候都需要用 matyhtf 的帐号

这是好事啊

异步可不是加上 libuv 就兴趣，所有的 IO 操作都需要支持，目前也就 golang 做得还行了

@mxalbert1996 是啊，我就是这么理解的（我说的什么话让你误解为理解成别的意思了？）


@cwcc 我觉得不仅是『不是很好』，而是『是很不好』。之前在商业化的过程中韩已经不止一次有被批评过激的行为了，但看了 contributor 的统计后我也不奇怪了。因为韩的代码量的确是压倒性的。

Swoole 娱乐圈

只能说 swoole 作者功利心太强

在用 webman 代码不用改 直接翻几倍的性能，性能测试比 go 还牛。 这算 php 唯一的清流和希望了。

swoole 吃相有点难看了，php 半死不活的，有一半原因是他们瞎搞……swoole_cli 如果还这样 就彻底放弃他们了

应用容器用 workman 就行，性能好，功能全。另一个项目频出公关事故，不适合用于长期项目。

我个人使用过 Workerman ，感觉性能是很强，但是里面的东西非常不组件化，想要改些东西只能重写一整个文件，而且还不是 PSR 规格的。Swoole 做得还算可以，有啥用啥，但是作者搞的每次操作非常迷。
@towser

行走在荒野之上的 rustman 路过

PHP 是我主要使用的语言，但是我不建议用 swoole ，需要它的场景都能用 go 或者 node 替代，如果需要跟 PHP 互动，就暴露 Api

赚钱不寒碜，但是藏的不够深，被发现了

1. 尝试过推 swoole 收费版，性能更强，被吐槽了，说是拿商业版做小白鼠测试，稳定了 merge 进开源版。
2. 韩天峰撇清，称郭新华的商业公司行为，结果一看股权结构，韩天峰是绝对控股的大股东。
3. 官方推荐 hyperf 时，存在明显对其它基于 swoole 的框架不公的情况，接着撕逼。
4. php fibers 投票的时候，拉拢中国有投票权的人投反对票，实名投的票，藏不住。
5. Dashboard 事件，震惊社区，这么偷偷塞 RCE 进去真的合适吗？

@sagaxu

1. Swoole 收费版确实非常需要吐槽，这很明显想赚钱想多了。
2. 商业关系内部人士，外面都显得很明显了也不多说。
3. 部分其他 Swoole 框架也存在生态建设排挤的情况，不是少数，不仅限 hyperf 。
4. Fibers 投票应该是立场不同，因为抛开 Swoole 作者立场，Swoole 本身和 PHP Fibers 理念会有冲突，是两个派的做法（ Swoole 和 swow 是 hook 派，官方对 Hook 底层的操作应该比较排斥，所以主推了 Amphp 系的 fibers ）。
5. Dashboard 事件没掀起大的波澜，但是我现在至少知道使用第三方非并入主线的扩展，包括 Composer 依赖，也并不比 npm 被投毒的概率小。

@cwcc 吹 swoole 的那帮人就是带节奏的，就没看到多少公司项目在用，有这成本的为了生态全使用方便干嘛不上 java. 喜欢折腾追新干嘛不搞 go

@cszchen 赞一个

@lap510200 还真有公司用，面试的时候考我。还有用 swoole 的嘲讽我，我说太初级搞不懂协程，才回想着用 Go 去解决，因为 Go 门槛低。。。

@cszchen 如果是小公司那估计就是装了。小公司哪有那么牛逼的 To c 项目, 而大公司用 hyperf 还不如 spring 直接搞微服务, java 生态更好，现成的轮子和解决方案多，招到对应的人更容易