@leeolsen 像我的性格，别说体制内了，我都受不了互联网大厂的约束。除了创业成功我想不出我能如愿的第二条路。

@leeolsen 你这算是活通透了。可是大部分人根本来不及活通透就得选择了。

好办法就是上传源码（滑稽

@lxdlam 你说的很对，所以虽然我个人不喜欢 2333 ，虽然 Go 是一种工程妥协（ Go 到处是工程妥协，比如现在还没完全上线的泛型），但是它毫无疑问是有用的。可以说 Go 语言这种编译器抽象对于大部分 Web 应用都是有效的，这本就是它的专长。

无效的领域，其实倒也不少。比如追求精确控制延迟的 real-time system 、高频交易之类的低延迟系统；比如本来就需要精确控制所有开销的游戏引擎、OS 内核、数据库系统。比如各种传统计算机算法。比如科学计算…… 但说实话这些本来就不是 Go 的专长。

我对于本楼有些微词的地方是，明明有这么多不同的场景，很多 Go 语言拥蹙就只知道互联网业务这一亩三分地，以为 Go 的协程就是圣经。。。互联网程序员现在网上的声音太大了，以至于 “技术” 就只有互联网并发 hhh

@statumer C# 那种可以通过一个线程池（专门排队做阻塞任务） + 非阻塞的 IO 。不过确实，非阻塞 IO 的库开发需要时间。所以这就造成了 Go 语言在网络微服务等领域特别被人追捧，因为在这里面编译期自动插入 hook 确实省事得多，一下子就可以适配所有阻塞的库。

这其实就是工程性的妥协了。C++ 和 C# 没有编译器的 hack ，导致大家不得不开发真正的非阻塞库。但是反过来，这样就倒逼 C++ C# 这种语言用户开发出真正高性能的非阻塞库了。然而毕竟真正需要高性能非阻塞的库不多，Network IO, MySQL / PostgreSQL / MongoDB ，加上一定的 File IO 和基础框架，就解决了。

其他的并不需要处理这种事情。应用逻辑方面需要解决“锁”的阻塞问题，其实“不阻塞”才是更正确的方案。逻辑复杂的应用从多线程并发阻塞模型换成 Actor model ，你会发现写起来就是第二次工业革命和第三次工业革命的区别。

Go 语言编译器允许大家偷懒，大家自然没有动力去精益求精，“够用就行”。反而抑制了更精巧的程序 —— 当然这也是做 “工作” 和做 “艺术品” 态度的差别吧 hhh

@lxdlam 在我看来 f(n) 就应该也是 async 的，虽然对于这方面 js 我不太熟。

我的技术背景是 C++、Python 比较熟，曾经用 Scala 写过 Future / Promise 的程序不过已经很久没有用了。C++ 自己写过 Actor framework ，Python 曾经用过 tornado 和 gevent ，现在挺喜欢用 async / await 。

因为我的这些背景，所以我觉得程序员非常准确明白所有这些并发方法（线程池、event loop 、callback 、future promise 、async await ）是基本功，而且不同任务可能偏重于不同的技术。当一个任务需要特别准确把握延迟的时候，随意上下文切换是不可接受的，那么就得手撸 event loop ，顶多在 event loop 上自己封装一下比如 actor model 或者 future / promise 呗。

所以我比较 anti go 语言这种类似于线程的协程吧，总感觉它管得太多了。

@statumer 我原先也完全是你这个理解思路，直到我在这一楼层里面看到了有人说 Go 语言的协程是可以切换上下文的——

https://www.jianshu.com/p/fb1ccbd0d0ff

我 tm ，瞬间五雷轰顶，并且明白了为啥 Go 吹那么多的原因。引用我 125L 的观点：

> Go 这种内置协程时间片切分的机制，在我看来，是一种工程实践上的妥协。
> 无论多轻量级的切换，一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。
> 如果能控制 IO 非阻塞让渡控制权，而且每对 IO 之间的操作都比较轻量（微妙级），就完全可以只在 IO 上切换。这样总体效能是最高的。
> 但是工程上不能保证所有类库都这样，也不能保证所有程序员都写的对，所以 Go 的这种协程才有用吧 hhh

所以本质上这是一个，因为不会用 event loop 的程序员太多了，Go 语言大爷们就说：算了，你们这群傻逼，干脆我语言创造一个比系统线程更轻的协程给你们用算了。

----

所以总结一下，Go 语言的协程和其他语言的协程是不同的。C++、Python 这种经典语言的协程 tm 根本不可能内置 Go 虚拟机的时间线分片。JVM 和 C# 也从未想过要这么干。微软的 Fiber 还差羽而归。因为它们发现，替程序员越俎代庖搞这种抽象，吃力不讨好。反正追求性能的有 event loop 或者基于 event loop 的单线程协程，为啥还要搞个不上不下的多线程（有上下文切换）的协程呢？

毕竟任何上下文切换，哪怕你说 Go 协程切换只要三个寄存器，tm 还是实打实有这个耗时的啊。
----

但是在一个没有泛型被认为是大道至简的语言里面，这种独一份的奇葩设计也没啥可奇怪的。

（强烈怀疑它没有优化好
（要用 transaction batch insert

你用了啥工具导入。。。有区别的

如果你在 foo 里面 a = 200 ，然后在 foo() 之后 print(a)，你会发现 foo 里面的 a 和外面的 a 就不是一个 a 了。

我觉得这是 Python 让人不满意的地方。因为没有声明，赋值即声明，所以会搞不清楚作用域。

事实上如果你运行如下代码：

def main():
....print(a)
....a = 1

a = 2
main()

你会得到一个异常：

UnboundLocalError: local variable 'a' referenced before assignment

原因是 a = 1 这句话在 main 函数里面定义了一个变量 a ，因此你在 print(a) 这一行就引用不到全局的 a 了。

@ob 你可以用 bootstrap-vue （ doge ）

https://bootstrap-vue.org/

1. vue.js + webpack 配合其他语言不是难事，比如我经常配合 python 。
2. vue.js 就是比 html bootstrap jquery 好写啊。。。

@liuidetmks 哦原来 C 语言的模拟 coroutine 其实是自动机 hhh

这样来看，这种其实更类似于 on_message(message_type) {
switch (message_type) {
case xx: ...
case xx: ...
}
}

只不过用了语法糖自动展开了

@kidonng Python 的标记收集 GC 很少运行啊，大部分 gc 都分摊在每一行上面了

@joshu 说实话，Go 这种内置协程时间片切分的机制，在我看来，是一种工程实践上的妥协。

无论多轻量级的切换，一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。你不会想要一个 for (1000000) 的计算任务被打断一千次吧，对吧对吧。

如果你能控制 IO 非阻塞让渡控制权，而且每对 IO 之间的操作都比较轻量（微妙级），你完全可以只在 IO 上切换。这样总体效能是最高的。

但是工程上不能保证所有类库都这样，也不能保证所有程序员都写的对，所以 Go 的这种协程才有用吧 hhh

@lxdlam 哦对。不过 Erlang 我也不太熟 23333

Akka 受限于 Scala 这个语言太。。。。学院派，不太关心工程实践，语法糖 >> 性能和可维护性，导致它不太广泛使用。