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把編譯器信息也簽名了且不支持卸載。想要玩熱拔插也走不通了。循環依賴的問題。以及各種不知是不是作者自己惡趣味的強制規定等等吧。

其實我個人愚見，這些往協程上面發展的語言本身就跑偏了，這本來就是多任務操作系統一直以來干的事情。我們編程就應該是線性的這是最自然的。現在把這種心智負擔加到開發人員身上不太合理，如果當下的操作系統不變革，不提供新的編程接口，那么就寄希望一種全新的操作系統問世吧哎。

鏈接：https://pan.baidu.com/s/1_4PIUb-Yl68aTW9Bw95iJA
提取碼：tnav

總結

以上是生活随笔為你收集整理的黑马Go语言与区块链学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。