Asyncio-vs-Curio: Worse-Is-Better

[guyskk0x0]

http://blog.guyskk.com/notes/Asyncio-vs-Curio-Worse-Is-Better

[kzing]

有想法, 有实践, 很酷

[jason0916]

可以的，支持

[neoblackcap]

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

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

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

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

[Wincer]

很不错，支持一下

[guyskk0x0]

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

这是我的理解。

[tkmiles]

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

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

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

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

[guyskk0x0]

@tkmiles 完全同意

[keysona]

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

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

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

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

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

适合的工具干适合事。

[cholerae]

个人感觉 python 的异步是各大主流语言里最为反直觉的一种设计。不是很懂 asyncio 的应用场景。不如用 Go。

[owenliang]

asyncio 辣鸡，基于 generator 的协程都是反人类 没前途。

[zhzer]

asyncio 虽然不友好接口各种冗余，但是够用了吧

并且 py 协程的社区环境一点都不活跃，新东西要发挥作用还是任重道远

[zhengxiaowai]

asyncio 概念太多了，而且好多相似的，很多接口缺乏 demo，到现在我也不知道是用来做什么的

[janxin]

asyncio 在 3.7 版本中添加了 asyncio.run()，在优雅性上切近了 curio

3.8 版本即将引入 asyncio.TaskGroup()和可能会有类似 trio 的超时和取消机制

这一点确实 asyncio 正在变得更好

[d18]

本来想用 asyncio 干点事，看了半天文档感觉很乱，而且相关的异步库支持也不够，很多还是非阻塞实现，于是转用 go 干活了。

[sleshep]

curio 的 dns 操作都放到线程池处理而不是像 tornado 一样可以可选接入 cares 等异步 dns 库是个暂时的小缺点
kernel.py 真的好长,look giant and insane

[qgb]

在 trio （和 curio ）中，核心设计原则之一就是你从不用回调编程;感觉更像基于线程的编程而不是基于回调的编程。