Python中Asyncio与Curio对比：Worse-Is-Better的异步编程探讨
http://blog.guyskk.com/notes/Asyncio-vs-Curio-Worse-Is-Better
Python中Asyncio与Curio对比：Worse-Is-Better的异步编程探讨
帖子回复：
哥们，这问题挺有意思。Asyncio和Curio确实是两种不同的异步编程哲学体现。
Asyncio走的是“Worse-Is-Better”路线——先解决80%的问题，让大多数人能用起来。它直接集成在标准库，API设计相对简单粗暴（比如loop.create_task()），生态庞大但有些地方确实“糙”（比如早期的事件循环API）。就像Unix哲学：先跑起来再说。
Curio则是“The Right Thing”的代表。David Beazley设计的这个库更注重正确性和优雅性，用async/await原语构建了一套更严谨的并发模型。它的Task、Timeout机制更一致，调试体验也更好。
简单说：
- 要快速上手、生态丰富：选Asyncio
- 追求代码优雅、教学研究：看Curio
两者现在都支持async/await语法，但底层理念差异很大。Asyncio像实用主义的丰田，Curio像精工细作的保时捷。
总结：按实际需求选，别纠结哲学。
想法很好，但是有几点可以讨论
"从表面上看，Curio 应该有更少的 Bug，因为它的设计更合理。实际使用后， 你会发现它和 Asyncio 的 Bug 一样多，甚至更多"
1. asyncio 在文中说 bug 比 Curio 少，那么按照定义 asyncio 又怎么会是 worse?
2. 接口以及用法应当一致，不应当有零零散散，格格不入的接口。
身为一个程序员我是认同这一点的，但是对于软件而言是否优秀而言，我又不这样认为。一致，那么跟什么一致？功能跟用途本身就是不一样，那么一致在哪里？比如 Unix 里面的一切皆是文件，所有操作都可以简化成 write 和 read。很一致对不对？但是我觉得网络跟文件本身就不是这样的东西，那么到底什么需要一致？如何界定呢？
而且当你在设计一个没有可以参考的东西，或者你想着有些创新的时候，那么一致是否那么重要？我觉得这个应该是更加符合人的使用习惯入手才是对的。一个新软件的使用，不管你设计得多么一致，大家都是从新入门。只有不断学习或者迁移已有的经验。那么如果更符合人的使用习惯，那么软件就可以称之为优秀，哪怕他们不一致，比如吃牛排的时候就用刀叉，吃中餐就用筷子。
1. Asyncio 在很早，还有很多 Bug 的时候就发布了，那个时候它是 Worse。
Curio 设计更细致，发布更晚，第一版就比较完善了，但此时 Asyncio 经过了几轮迭代，也比较完善了。
从设计者的角度，可能会希望等软件比较完善了（ Better ）再发布，但更好的选择是在软件基本可用时（ Worse ）就发布。
2. 比如 Curio 的 Socket API 和标准库的 Socket 是基本一致的，学习成本很低。而 Asyncio 是全新的 API，没有统一设计规则，给人的感觉就是不一致的。问题在于 Curio 过早地追求一致性，异步场景下必然会需要新的，不一致的 API。
这是我的理解。
抛开源码, 设计, 性能等等
至少看 curio 的源码至少能比较轻松的入门 python 中的 async, 协程的调度可以怎么做, 至于这么做好不好， 每个人都有自己的看法
而 asyncio 的源码, 理解的难度有点高
再者, curio 的目的只是一个 async 的"例子", asyncio 作为标准库, 自然有更多应用上的考虑
楼主辛苦了。
----
下面是些无关的话。
记得 flask 的作者曾经吐槽过 python 的 asyncio …
自己也曾花了点时间看 asyncio 的文档…虽然一段时间不用就忘光了，毕竟太多概念了…
以下是个人看法，若需要异步 io 或者性能等，个人会用 go 语言。
然后，文本处理、数据分析等会用 python。
适合的工具干适合事。
asyncio 在 3.7 版本中添加了 asyncio.run()，在优雅性上切近了 curio
3.8 版本即将引入 asyncio.TaskGroup()和可能会有类似 trio 的超时和取消机制
这一点确实 asyncio 正在变得更好
