@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 这个语言太。。。。学院派，不太关心工程实践，语法糖 >> 性能和可维护性，导致它不太广泛使用。

@kingofzihua 另外 actor 模型可以很容易插入中间件。在一个 IO actor 和一个业务 actor 之间你可以完全不用更改两边，插入流控 actor ，或者插入错误重发 actor 。一个业务 actor 也可以搭配各种不同的协议 actor ，比如把一个 HTTP 协议 actor 丢在 SSL 信道 actor 或者 TCP 信道 actor 上都不用更改 HTTP 协议 actor 的任何一点代码。

P.S. @kingofzihua 补充一句，actor model 里面每个 actor 其实是个状态机。差不多就是


def __init__(self):
....self.state = 0

def on_message(self, msg):
....if state == 0:
........do something with msg
........self.state = 1
....elif state == 1:
........do something with msg
........self.state = 2

核心就是这个 on_message 处理函数。你是期待框架把新的数据推送给你（或者别的专门读数据的 actor ），而不是在每个 actor 里面都调用 read 。

这个的好处在于，你可以把 IO actor 和业务 actor 切分，业务不用管太多 IO 细节，实现了解耦。单元测试的时候你可以直接对业务 actor 伪造输入进行测试。特别爽。

而且状态机可以回退，这个就可以实现很复杂的东西。

…… 不过实现一个基本的 actor framework 也不是那么困难的。。。

再比如我自己在自己的项目里面用 C++ 实现了一个。

@kingofzihua 对既然提到了 actor model ，楼主如果有兴趣可以去看看 actor model ，这个东西的思考方式会让你改变很多对并发的看法。比较成熟的 actor model 的实现大概只有 scala akka 。

actor model 的核心在于，每个 actor 只有一个工作线程。actor 尽量避免阻塞。即使你在 10 个线程的线程池上运行 10000 个 actor ，每个 actor 要同时处理其他 9999 个 actor 发来的消息，也保证只有一个线程在运行一个特定的 actor 。这个是 actor model 最重要的特性。

@2i2Re2PLMaDnghL 就我个人而言，Actor 模型和 callback / future / 协程不是一个维度的。

actor model 的优势在于 state + mailbox 。每个 actor 上面有个单独的等待队列，即便你在线程池上跑 actor model ，也不会让一个 actor 在多个线程上运行。这使得你可以很安全地编写出来双向交互的 actors ，而不用担心每个 actor 内部的数据存在竞争关系。

线程、协程、callback 、future ，数据流一般是单向的，一个 IO 线程在启动一个后台任务以后就陷入等待，不会处理任何其他事务。而 actor model 每个 actor 都有一个微型 event loop ，完全是全双工的。

你可以很容易用线程池实现 actor model ，避免阻塞调用就能实现完全非阻塞。你也可以在协程上实现 actor model 。或者你也可以在 event loop 上实现 actor model 。总之 actor model 是高于并发的一个抽象模式，核心在于数据封装。

通常一个应用程序服务器可以划分为两部分线程组：

1. IO 线程，处理网络 IO 、数据库客户端、等待后台任务、（轻量计算）汇总各种结果。
2. 计算线程，应当是固定数量的线程组成的池，这样一个计算任务丢进来可以排队。

也可以是分离的进程乃至于不同机器处理这些不同的事情。如果是不同进程，可能就会上 zmq 之类的 ipc message queue 。如果是不同机器，那么就会上 rpc 、http api 、redis 或者更重量级的 mq 。

@kingofzihua

1. 对，协程只对非阻塞 IO 起作用。
2. 但其实，所有上述的并发方法都是针对阻塞 IO 减少开销的。对于 CPU 密集型任务，如果只有 2 个核，同时跑 4 个矩阵计算是没有意义的。
3. 在实践中，通常把 IO 任务和计算任务分开。IO 靠比如 Promise/Future ，event loop ，协程搞。如果需要调用计算任务，就扔到一个固定线程数的线程池上跑，然后协程进入 await 。等计算完成 await 被唤醒，再继续做后面的 IO 。

@0o0o0o0 其实感觉 async/await 就是协程的一种（个人认为最优美的）表现形式。然这需要大量语法糖支持。

Python 和 JS 的 await 都已经上线了，用起来其实挺爽的。只是 Python 方面的支持库力度还不行。

C++20 的 coroutine 虽然语法糖标准已经发布了，但是根本没有支持的库（差评）。还得等几年。

其实这里有两条技术路线

callback => promise / future
event loop => coroutine

要理解协程就要去理解这两条技术路线的区别。

并发种类：

1. 多线程：太慢

2. callback：代表作为 Node.js 、python tornado ，boost asio 。但是会陷入 callback 地狱。

3. Promise / Future：java, scala, js, 比 callback 好多了，目前是主流技术之一。缺点是要仔细管理闭包的嵌套。

4. event loop：一般 c/c++ libev libuv ，还有 python gevent 。心智负担比上述三种都大，但是可以更精细操作、更高效。底层实现一般为 kqueue 和 linux 上的 epoll ，或者 fallback 到 select 。

大名鼎鼎 nginx 就靠 event loop 暴打同时代。

5. 协程。

协程一般用 event loop 实现，这种协程就是对 event loop 的抽象。要理解协程，建议稍微学习一下 event loop 。

“如果阻塞是系统调用阻塞，线程就会挂起，调度到其他的线程了，你协程没用”

所以协程要配合非阻塞 IO 。

原先 callback 或者 Future.map 就是非阻塞的，但是写起来心智负担太大。所以抽象了一种 IO ，形式上是阻塞的，但是实质上是非阻塞的。await non-blocking read 会把控制流立刻转向其他协程，而当这个 non-blocking read 成功以后这个协程会重新进入调度队列。

1. 虽然原则上在 mac 上开发 linux 上运行的 c++ 也不是不行。
2. 但是最方便的还是在对应平台上开发，不然断点调试麻烦。
3. 所以你可以买一台比如，联想

@3dwelcome 真没必要这么快。Typora 的渲染速度已经够了，看上去也不是纯 GPU 的亚子.