@iseki
> 但是编程时如果每次自己去搬这一个个砖头这既不符合 DRY 的原则也不够“少”。

这个完全赞同，所以我选了 go 之后基本没再回头写多少 c/cpp 了，因为没必要，go 太省事了，而且绝大多数场景也不需要极致的性能、反而更需要开发效率

> async await 算是结构化并发的一种落地形式。

但这比起 go func()来，便利性可读性还是差得多

> 你不能说封装的程度高就一定是不好的，软件工程是权衡和妥协，君不见 Go 相比 C 不是也隐藏了许多细节吗，每个函数开头插入栈空间检查未必是个多么高效的选择，当年也有人因为用了“高级语言”就被喷浪费了机器性能。
> systemd 出现之前，如今一个 .service 文件搞定的事情要一位 bash 熟练工写上成吨的 .sh 还不一定好好解决问题。看上去 shell 里的每一个命令都好简单啊，但是组合起来的结果你能说这是“简洁”的吗。当然这个我不多说，我相信每一个工程师都很清楚。

我当然不是反对封装程度高，而是反对不必要的过度封装。
而且要分开不同的层次，一个是语言级的，一个是框架级的。
go 也好 java 也好，它们在 runtime 内的实现，都是语言级、不需要使用者去关心太多内部细节。
而框架这一层，至少我觉得 Java 是属于过度封装的，比千层饼的层数还多。。好处是更可靠，坏处当然是牺牲性能、以及真遇到问题时使用者难于深入到一层一层内部去发现和解决问题。

> 此外 Java 的轻量级线程和 Go 的 goroutine 差不多一回事，当然 syscall 该卡还是卡，go 也是在 IO 等等地方特殊处理掉的，这个不是应用程序自己做点什么就能解决的。（其它关于 Java 的内容我就不评论了，这个看场合见仁见智

这个 `当然 syscall 该卡还是卡` 要看是怎么个卡的方式，是卡协程但协程会被调度、还是卡了系统线程。
我前面 #135 里提到的 `系统调用之类的接口` 其实没说完整，准确点讲应该是 `把系统调用那些封装起来然后提供给用户的接口`，例如 go 标准库 net.Conn.Read：虽然它是阻塞的，但它不会阻塞系统线程，实现方式就是当前读不到数据时就调度了并且等待可读，runtime 里的 iocp/epoll/kqueue 等待可读事件到来再唤起。go 里直接去调用可能阻塞的 syscall 也还是可能阻塞，但标准库对于 socket fd 封装出来的 net.Conn 之类的接口都是被 poller+调度这样搞定了的，所以使用标准库的这些是真的可以写同步代码也不会导致线程池阻塞耗尽之类的。
Java 的轻量级线程如果没有配套实现全套的类似 go net.Conn 这些的话，那可能还是没有解决阻塞系统线程的问题，那至少从语言级上，就不是一个类型、不是同一可用级别的协程系统、是没有可比性的