我对 python 最不满意的地方就是加了这个特性。

js 最大的失误也是加了这个特性。

【 在 leadu (leadu) 的大作中提到: 】
: async/await是c#2003年发明的，别的语言现在都抢着往自己里面塞
: rx也是c#搞得，java和js也没见少抄
: 特性加的好，谁爽谁知道
: ...................
--
FROM 124.72.119.*

不是不支持协程，，没看我怎么说的，“多用协程解决一切问题“。

我比较希望 js 能够隐式地支持协程。。

c# 为什么选择 async/await 两个关键词，因为 c# 本身是支持线程的，老旧的 c# 程序都会调用 win32api 里面的阻塞 IO API，以及创建线程做并行计算. 为了在阻塞 IO 这一套语义之外并存地支持协程，c# 不得不额外支持 async 函数，显式地告诉程序员，这是个协程操作。

而 js 不一样。js 目前所有的运行环境，不论是浏览器还是 node，都是单线程并且异步的。根本不存在 c# 阻塞 IO 的情况。如果我是 js 的设计师，我不会无脑抄袭 async/await 这一套恶心的东西。而是会要求所有的 IO 操作必须隐式支持协程。也就是说，所有的 js 函数，自动地加上 async 前缀，所有调用 async 函数的地方，自动地加上 await. 不想要自动 await 的话，就加个 spawn 关键字，返回 promise (实际应该有个额外的 task 类型，用于 cancel() 协程)

python 的情况和 c# 类似，但是 python 本身拥有 gil，所以实践上 python 开发者使用线程多半是为了调用底层的阻塞 IO API，很少用于计算的。如果我来设计 python，我会直接把 gevent 并入语言核心。

实际 stackless python 搞这一套已经搞了十几年了。js 社区好像发现新大陆一样。唉。。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: once await ， never back
--
FROM 124.72.119.*

js 是单线程的，哪有什么全局锁啊。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 比如 全局锁，然后 判断的时候 io 等 协程了。
: 大概这样的代码
--
FROM 124.72.119.*

这句话有问题吧：

$user=UserModel::Get($id);

UserModel::get() 如果知道有网络请求，那么，要么写成 promise 异步非阻塞回调，要么在子线程里面处理也是异步阻塞回调，要么协程同步阻塞。无论哪一种情况，对 $user 都得加锁啊。

这个锁是业务锁，它的存在是一种业务需求。跟协不协程没有关系。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 比如 php swoole 用第三方 composer 库  static 变量问题。
: function getUserByIdCachely($id)
: {
: ...................
--
FROM 124.72.119.*

这个不是事。对于内部无 await 的，编译器可以很自动化地编译成普通函数。

显式 async 的问题很大，你们其实都没考虑过，它无法穿透系统定义的函数。

比如 Proxy 定义的 getter/setter，如果要实现一个需求，某个 obj 的 property 由远程决定是否存在，以及设置 property 的值，会自动地修改远程的值。显然 Proxy 是做不到的。这个功能常用于 python 的 rpc, python 应用 gevent 后可以做到而 js 不行。

想要实现上面那个需求的话，js 就不得不再定义一个 Proxy 的 async 版本了。

这就是我为什么说 js 是一门垃圾语言的原因。

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 哪怕io操作都要协程化，为啥所有函数都要async？我写个1加1纯计算函数也要进事件循环？
--
FROM 124.72.119.*