Asyncio-vs-Curio: Worse-Is-Better

想法很好，但是有几点可以讨论

"从表面上看，Curio 应该有更少的 Bug，因为它的设计更合理。实际使用后，你会发现它和 Asyncio 的 Bug 一样多，甚至更多"
1. asyncio 在文中说 bug 比 Curio 少，那么按照定义 asyncio 又怎么会是 worse?

2. 接口以及用法应当一致，不应当有零零散散，格格不入的接口。
身为一个程序员我是认同这一点的，但是对于软件而言是否优秀而言，我又不这样认为。一致，那么跟什么一致？功能跟用途本身就是不一样，那么一致在哪里？比如 Unix 里面的一切皆是文件，所有操作都可以简化成 write 和 read。很一致对不对？但是我觉得网络跟文件本身就不是这样的东西，那么到底什么需要一致？如何界定呢？

而且当你在设计一个没有可以参考的东西，或者你想着有些创新的时候，那么一致是否那么重要？我觉得这个应该是更加符合人的使用习惯入手才是对的。一个新软件的使用，不管你设计得多么一致，大家都是从新入门。只有不断学习或者迁移已有的经验。那么如果更符合人的使用习惯，那么软件就可以称之为优秀，哪怕他们不一致，比如吃牛排的时候就用刀叉，吃中餐就用筷子。

Wincer

2018-07-29 17:33:35 +08:00 via Android

很不错，支持一下

guyskk0x0

2018-07-29 17:51:06 +08:00

@neoblackcap
1. Asyncio 在很早，还有很多 Bug 的时候就发布了，那个时候它是 Worse。
Curio 设计更细致，发布更晚，第一版就比较完善了，但此时 Asyncio 经过了几轮迭代，也比较完善了。
从设计者的角度，可能会希望等软件比较完善了（ Better ）再发布，但更好的选择是在软件基本可用时（ Worse ）就发布。
2. 比如 Curio 的 Socket API 和标准库的 Socket 是基本一致的，学习成本很低。而 Asyncio 是全新的 API，没有统一设计规则，给人的感觉就是不一致的。问题在于 Curio 过早地追求一致性，异步场景下必然会需要新的，不一致的 API。

这是我的理解。

tkmiles

2018-07-29 19:30:40 +08:00

抛开源码, 设计, 性能等等

至少看 curio 的源码至少能比较轻松的入门 python 中的 async, 协程的调度可以怎么做, 至于这么做好不好，每个人都有自己的看法

而 asyncio 的源码, 理解的难度有点高

再者, curio 的目的只是一个 async 的"例子", asyncio 作为标准库, 自然有更多应用上的考虑

guyskk0x0

2018-07-29 19:38:09 +08:00

@tkmiles 完全同意

keysona

2018-07-29 20:21:32 +08:00

楼主辛苦了。
----
下面是些无关的话。

记得 flask 的作者曾经吐槽过 python 的 asyncio ....

自己也曾花了点时间看 asyncio 的文档...虽然一段时间不用就忘光了，毕竟太多概念了...

以下是个人看法，若需要异步 io 或者性能等，个人会用 go 语言。

然后，文本处理、数据分析等会用 python。

适合的工具干适合事。