- 主题:把js全干掉,统一成ts,有没有搞头?
async解决的第一个问题是单线程零开销异步io，gevent怎么解决？
【 在 qingant (傅红雪) 的大作中提到: 】
: await解决的所有问题，gevent都解决了，而且不带来任何代价，对Python来说这就是简单的事实。
--
FROM 27.91.71.*
我看在python里面写create_task比写thread更安全些
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 所以我一直说你对 python 不了解，
: 我前面说过 async/await 对 c# 是好东东。也很适合移植到 java 和 rust 上面。
: 但对于 python/js 这种事实不支持线程的语言，gevent 就是最好的解决方案。async/await 是大毒草。
: ...................
--
FROM 27.91.71.*
我不太清楚Go的玩法，不过正如我刚才说的，task或者promise可不一定是一个并发对象，这东西本质就是一个可等待对象，可以是event，线程，协程或者任何其他东西
【 在 qingant (傅红雪) 的大作中提到: 】
: 我做得从上层看和Go是一样的，就解决并发这个问题的角度讲，Go难道不比async/await的方式强吗？
--
FROM 27.91.71.*
那么go关键字还是比await要重的多啊
【 在 leadu (leadu) 的大作中提到: 】
: 我前一段时间简单了解过，go的协程其实是ThreadPool.QueueUserWorkItem，毕竟作者之一是os出身的，搞的也和windows xp的QueueUserWorkItem路数是一样的
--
FROM 27.91.71.*
不是有没有必要，在最近几十年的OS内核里，所有的I/O都是这么实现的
await只不过是一种简单不容易写错的手段。
【 在 qingant (傅红雪) 的大作中提到: 】
: 不是一码事。
: await是一种控制流的抽象，表示要等一个异步对象的结果。事实上没必要，就强迫所有控制流都是同步的就行了。
--
FROM 27.91.71.*
我看await的最重要意义，就是防止为了同时下载N个文件而开N个线程（或者fiber协程之类）。。。
【 在 qingant (傅红雪) 的大作中提到: 】
: 疯了跟你讨论。从编程语言的角度来讲，我们考虑的是怎么抽象控制流，提供什么样的思维模型，提供全同步的模型行不行？显然行，因为它的心智模型是最简单的。那么问题就是这样的模型是不是能够足够优化的实现，我们的回答也是简单的yes。既然这样，同步编程模型+调度优化
--
FROM 27.91.71.*
实际上C#的thread内部有fiber支持，两个managed thread id可能是同一个thread在跑。
await解决的根本就不是协程问题了
【 在 leadu (leadu) 的大作中提到: 】
: 嗯，又加了个channel来返回值，加了个叫啥WaitGroup的来提供很弱的等待功能。
: 剩下的协程调度流控什么的全没有
--
FROM 27.91.71.*
其实看到老鱼开始骂微软，就代表基本赞同你的观点了
【 在 leadu (leadu) 的大作中提到: 】
: 哭了，聊这么半天我才反应过来
--
FROM 27.91.71.*
因为用qtcreator写javascript的时候，这些真是问题
【 在 eGust (十年) 的大作中提到: 】
: 你看，你对 !!true、0.1 + 0.2 == 0.3 这种问题都有疑惑，总是让人忍不住嘛
--
FROM 27.91.71.*
本来昨天挺热闹的，你直接把天聊死了。。。
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: async不就是promise的另一种写法吗？
--
FROM 27.91.71.*