范型是另外的东西，属于go语言设计的问题

go的协程好用，其一是语言层面只支持协程，消除了同时支持多套机制的各种麻烦；其二是开销很低（相对线程）而且逻辑上可以完美替代线程；外加channel的支持

async嘛，一般是generator实现的，属于一个不上不下的抽象：一方面会与既有的线程/协程并存，导致同时支持多种机制的麻烦；另一方面自身又依赖线程/协程提供执行能力。这就很尴尬了

【 在 ensonmj 的大作中提到: 】
: go的协程比async好的一点是同步异步都能用。但go的范型太弱了  
--
FROM 221.218.208.*

【 在 Bernstein 的大作中提到: 】
: 讨论技术，从基本假设和认知出发，不需要遵守哪个委员会的看法
~~~~~~~~~~~~~~~~~~~~~~这是评价判断，是由评价者的价值观和经验来支撑的。
主观判断和客观判断都分不清楚啊
: 好用不好用，谁都可以判断，不需要哪个委员会规定
: 你要遵守委员会规定，可以当个AI，反正gpt什么的都已经成熟了
: ...................
--
FROM 123.116.219.*

async来自于函数式编程语言社区Join calculus，你说它“不上不下的抽象”，真敢啊
这就是我想批评的，普通又自信的程序员，水平差还喜欢评价

【 在 Bernstein 的大作中提到: 】
: 范型是另外的东西，属于go语言设计的问题
: go的协程好用，其一是语言层面只支持协程，消除了同时支持多套机制的各种麻烦；其二是开销很低（相对线程）而且逻辑上可以完美替代线程；外加channel的支持
: async嘛，一般是generator实现的，属于一个不上不下的抽象：一方面会与既有的线程/协程并存，导致同时支持多种机制的麻烦；另一方面自身又依赖线程/协程提供执行能力。这就很尴尬了
: ...................
--
FROM 123.116.219.*

对。协程这东西是 all or nothing，要么整个语言提供支持限制其它方案，要么别支持了以 green thread 的形式存在，作为 native thread 的一种无感知优化即可。搞得不沦不类的没意思。

数来数去，还是咱 Java 好啊。本青打算继续切回 Java 挖啊挖代码。

【 在 Bernstein 的大作中提到: 】
: 范型是另外的东西，属于go语言设计的问题
: go的协程好用，其一是语言层面只支持协程，消除了同时支持多套机制的各种麻烦；其二是开销很低（相对线程）而且逻辑上可以完美替代线程；外加channel的支持
: async嘛，一般是generator实现的，属于一个不上不下的抽象：一方面会与既有的线程/协程并存，导致同时支持多种机制的麻烦；另一方面自身又依赖线程/协程提供执行能力。这就很尴尬了
: ...................
--
修改:hgoldfish FROM 117.24.94.*
FROM 117.24.94.*

你分不清啊，你的言论有什么判断力？

你说话的时候，除了攻击贬低他人，给自己的言论找个好爹，还有什么判断力？

【 在 leadu 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~这是评价判断，是由评价者的价值观和经验来支撑的。
: 主观判断和客观判断都分不清楚啊
--
修改:Bernstein FROM 221.218.208.*
FROM 221.218.208.*