Asyncio-vs-Curio: Worse-Is-Better

有想法, 有实践, 很酷

可以的，支持

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

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

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

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

很不错，支持一下

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

这是我的理解。

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

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

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

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

@tkmiles 完全同意

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

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

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

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

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

适合的工具干适合事。

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

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

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

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

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

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

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

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

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

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

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