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