GO语言统一了协程混乱的生态
协程并不是Go特有的专利，很多语言都有协程这个概念，比方说很多语言支持await/wait for，lambda，yield，loop，next……这些关键字的配合使用也只提供了一种从程序当中“中断”的能力，对于协程作业来说还远远不够。但是协程的实现其实是比较依赖操作系统的，所以别的语言在语义层面上支持协程的力度会显得非常非常地保守，作者更愿意把这件事情交给“协程库”去实现，从而不让自己的语言本身和操作系统形成强依赖。协程库很多比如fiber，libev，gevent，twisted，tornado。程序什么时候“中断”什么时候“恢复”这里就需要“事件”来驱动，各家有自己的事件驱动模型eventloop。导致的结果就是各家的eventloop互不兼容，你使用tornado，如果要连接redis，这个io就必须要进入tornado-ioloop，得找tornado-reids来完成，而不能使用twisted-adbapi。你的任何io操作都必须是要能被这一家的eventloop驱动，而这家的生态配套真的有这么全面吗？这是一个疑问。而Go语言就做的激进一些，语义层面就用select go channel把这个过程给抽象了，并且告诉你这就是go语言的最佳实践，所有的类库都是围绕这个天然的selector来构建，各种类库天然就互相兼容。当然语义上支持协程的语言不仅仅只有Go还有erlang，scala等等等等，但是为什么go关注度这么高，我觉得还有一个回避不了的问题就是go的爹是谷歌。
GO语言降低了协程编程的门槛
曾几何时，“协程编程”还是极少数高端玩家嘴里的黑话。无锁队列，并行，非阻塞，无栈有栈协议，上下文切换，actor ，csp这些黑话足以把你的膀胱吓得漏液。如今，作为资深c/c++工程师的你看到一个java crudboy看3个小时go cookbook 写出来的socket服务器的丑陋代码一开始你可能还会笑出声，但是一顿profile benchmark之后，你发现这丑陋玩意儿居然能比你花了半个月用c写的构建于colib+libuv+#￥%*&等一大堆你生怕写到简历上会引来一大堆猎头骚扰的黑科技构建的tcp服务端性能更高跑的更快的时候，笑容开始凝固并逐渐消失。go程序似乎不需要刻意调优，也不需要使用supervisor托管一堆进程，天然把协程分配到各核心上面自动压榨，而这一切还对程序员透明。终于你进入了“中年危机”。。。。。。
那GO语言是完美的吗？
孱弱的对象体系，由于Go语言缺乏泛型和继承，而只能使用的类似ruby的brought/mixin来extend class导致go不太适合写业务逻辑，特别是多人合作开发业务逻辑。还是会写到处写不利于维护的重复代码。
缺乏泛型和元编程能力，这个相信做过框架类的玩家应该懂的。
还有一些，诸如不支持像c/c++那种fork，你可能会觉得go不需要fork，但它居然wrap了sockpair这种典型的父子进程ipc，是不是有点精分，说好的原则呢？plugin把编译器信息也签名了且不支持卸载。想要玩热拔插也走不通了。循环依赖的问题。以及各种不知是不是作者自己恶趣味的强制规定等等吧。
其实我个人愚见，这些往协程上面发展的语言本身就跑偏了，这本来就是多任务操作系统一直以来干的事情。我们编程就应该是线性的这是最自然的。现在把这种心智负担加到开发人员身上不太合理，如果当下的操作系统不变革，不提供新的编程接口，那么就寄希望一种全新的操作系统问世吧哎。
链接：/s/1_4PIUb-Yl68aTW9Bw95iJA
提取码：tnav
