对。Python加async/await完全没必要，一个库用了这个，就扩散到整个项目
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你那个 fiber 的那句话就是错的。说跟 mssql 相关是 msdn 的原文，不过我一时半会给不出出处。win2k 还是 win98 时代就有的我忘了，内部先用的，后来移植到 win32api.
: async/await 也不是啥新奇玩意儿。python 原本支持的语法叫 yield from 完全等价于 await，当年 python 改动关键字的那个 c 补丁我都看过，没几行代码基本就是数据结构改名和增加关键字就完事了。再早的是 yield 实现的，搭配 twisted inlineCallbacks() 使用，更早的话
: 但是有一说一，确实是 c# 首先使用 async/await 这个关键字。
: ...................
--
FROM 47.56.237.*

嗯，async/await对JS是利益大于成本的，但是对Python完全是入不敷出的
【 在 eGust (十年) 的大作中提到: 】
: async/await 本来就是 promise 的语法糖啊，跟 promise 一点区别都没有。
: promise 虽然扁平化了 callback hell，但它还是用的 callback，不利于代码流的控制。引入 async/await 之后，所有的 callback 就都被移除了，变量都在同一个 scope 里面，在 catch/finally 里可以直接用，不用再特意跑到外层去构造一个 closure 专门用来放变量。降低了
--
FROM 47.56.237.*

我觉得在JS里面还行，毕竟和之前的回调和promise相比算是改进，Python的async/await相比gevent是劣化了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 我是不喜欢写 async 这个关键字，不是不喜欢 async.
--
FROM 47.56.237.*

事实上gevent几乎解决了所有问题，如果和async/await比的话，gevent解决了所有async/await试图解决的问题
【 在 leadu (leadu) 的大作中提到: 】
: 因为多线程开发有各种情况，编译器或库无法决定所有行为
--
FROM 47.56.237.*

我之前做过类似gevent的协程方案的，用C++做一个Lua的运行时，在运行时层面把所有IO调用转成协程自动调度，用起来就和Go差不多。所以就专业性来说，我不一定比这些语言设计者弱。
【 在 leadu (leadu) 的大作中提到: 】
: 多写几年多线程代码你和老鱼就明白区别了，最好是c++/rust这种语言的多线程代码。
: 在一个人不清楚明白会遇到的问题之前，是无法对其讲清楚这些问题的解决方案的。他会以为各种解决方案都是一样的
: 各个语言纷纷从dotnet社区一个字母都不改的抄async/await走，是因为dotnet这方面对并行计算有很大突破的。
: ...................
--
FROM 47.56.237.*