回复 《吐槽swoole》

看到这篇博文，深感欣慰。有人喷是好事，说的好的地方对我们是巨大的帮助。实话说口水战没意思，我对这个毫无兴趣，只是为了传播的更广。

后面不会再喷Node.js了，主要原因是：

1. 我不是资深的Node.js用户，而且swoole和Node.js定位不同，发展方向也不同。没办法公平比较
2. 避免Node.js的粉丝们来攻击我，我也没空余时间来争吵

关于此文中的内容，我针对性的回复一下：

1. 无论是swoole还是Node.js，都是解决IO密集型问题的。计算密集型的大家开多个进程都可以用到多核。
   但swoole IO密集部分也是可以利用多核的（基于多线程的EventLoop），Node.js不行。
   下面有Node.js的用户评论了“使用用Cluster”，这个是可以的，但有2个问题解决不了。
   更多细节请看：http://my.oschina.net/matyhtf/blog/289829
2. redis,memcache,mongodb的异步化。这个我们后续会支持的。swoole才发展不到2年时间，不可能一下子就全部都支持到。
   另外，复杂的业务逻辑，不建议用异步，同步阻塞就好了。swoole提供的异步MySQL不见得有几个人用。
3. 异步文件读写，这个我为什么敢喷Node.js，我有资格。Node.js用的4个线程阻塞IO模拟异步，遇到大量并发读写文件时，线程数自然就是瓶颈了，所以Node.js的异步文件API不堪大用。
   而swoole用了Linux Native AIO（需要加编译参数开启），遇到大量并发读写文件，一样可以胜任。
4. 像Node.js这样全异步回调是好事么？未必。各有各的好处和适用场景。异步的程序很难写，维护性太差。所以偏底层追求性能的就用异步，偏应用层面就用同步阻塞。这也就是swoole和Node.js理念上的最大不同。swoole既支持异步，又可以同步。还可以半异步(EventWorker)，半同步(TaskWorker)。

另外：

1. 就像你说的Node.js不仅仅是Net部分，Swoole也不仅仅是Net部分。
2. 你没看过Swoole源码，我可是看过Node.js源码的，并且做过大量的分析。可能比你还要懂Node.js底层
3. 你对我博文吐槽部分，有不少错误的地方