修正：我知道我沒有把本文的觀點(diǎn)表述清楚。我不會說GO語言有問題，或者它應(yīng)該做些什么改變，因為它跟Erlang語言不一樣。我準(zhǔn)備說的是GO所做的選擇讓它難以與Erlang在實(shí)用性和低響應(yīng)高并發(fā)需求的后臺應(yīng)用上抗衡。有必要注意一下，我不會寫像Julia語言一樣的東西。我聽說不管是新項目還是老項目，GO都被定位為Erlang的競爭對手。沒有人會對JULIA語言說這樣的話，但GO和Node.js倒是被一些人看作是Erlang很好的替代品。Erlang不能解決所有的問題！本文主要談?wù)摰氖悄男┑胤紼rlang適合使用而GO卻不適合使用。

　　我打算不帶主觀意見，用公正的眼光來看待GO，先將自己對它不喜歡的部分遺忘，比如說語法或缺乏模式匹配，并且解釋語言本身和運(yùn)行環(huán)境的類型系統(tǒng)的某些不適應(yīng)的客觀原因。雖然它有很多缺點(diǎn)，但我打算先從其好的部分說起。

　　GO語言的亮點(diǎn)

　　客戶端

　　正如Rob Pike所寫的，它最大的驚喜就是GO語言吸引了許多Python和Ruby的開發(fā)人員，而不是C++的。對于我來說我很樂于看到這種趨勢。不再有用pip和gems安裝的運(yùn)行速度慢的客戶端了�。�雖然由于某些原因Node.js用于客戶端的人數(shù)在增加，TMD keybase呢？）

　　GO通過垃圾回收和并發(fā)原語能讓開發(fā)人員快速，簡單的使用高級，靜態(tài)語言。同樣地，這也可能是C++轉(zhuǎn)戰(zhàn)GO的一個重要因素，在我電腦上跑著的程序（Hipchat和Spotify）經(jīng)常崩潰都是因為C++喜歡濫用內(nèi)存。但Rob Pike指出C++的開發(fā)人員不想使用簡單強(qiáng)大的GO語言。但Ruby和Python開發(fā)人員很樂意轉(zhuǎn)戰(zhàn)GO。

　　工具

　　在不依賴于第三方工具的情況下能輕松使用第三方庫來構(gòu)建可執(zhí)行文件，這都是GO的亮點(diǎn)。雖然這些工具不太完美，但有一些工具能彌補(bǔ)這些缺點(diǎn)，比如說Godep。對于GO來說這也是一大勝利。

　　GO的不足之處

　　當(dāng)GO被用來寫低延遲容錯系統(tǒng)的時候，它的一些設(shè)計決策是有害的。

　　并發(fā)性

　　是的，在第一部分我已經(jīng)額外的提到了并發(fā)原語。這是GO在替代Ruby，Python或C++作為客戶端語言的情況下作出的說明。但當(dāng)需要寫容錯的后臺程序時，在共享狀態(tài)方面GO和其它語言一樣爛。

　　搶占式調(diào)度

　　在這方面GO語言要好一些。GO語言的搶占式調(diào)度是針對系統(tǒng)調(diào)用的，但現(xiàn)在，當(dāng)goroutine檢查所有函數(shù)調(diào)用的堆棧時搶占就能發(fā)生，如果goroutine的運(yùn)行周期比以前的長，那么這很可能會被標(biāo)記為失�。ㄟ@將會造成搶占）。雖然這是一種進(jìn)步，但還是滯后于Erlang的減少計算和最近為改進(jìn)C集成而新增的臟調(diào)度。

　　垃圾收集

　　在GO中垃圾收集是全局標(biāo)記和清理垃圾的。在清理垃圾時會暫停所有的goroutine，而且等待時間很恐怖。低等待時間是很困難的，執(zhí)行時間越長，它就能為你做的越好。

　　錯誤處理

　　如果返回值為nil，不僅僅只是沒有異常和使用檢查。Goroutine沒有身份標(biāo)識，這意味著GO缺乏連接和監(jiān)控goroutine的能力。沒有連接（它使用的是panic和defer）和進(jìn)程隔離，意味著你不能以穩(wěn)定的狀態(tài)避免死機(jī)和重啟。在產(chǎn)品中會有BUG，而且許多BUG都是Heisenbugs，所以能讓進(jìn)程與進(jìn)程之間隔離開來但要基于他們之間依賴，是容錯的關(guān)鍵。

　　在處理錯誤的重大遺漏上，GO有nil。它在2014年是如何被認(rèn)為可以的，目前我腦海中還沒有任何概念。先不管它，稀里糊涂的看看再說。

　　內(nèi)省

　　沒有REPL對開發(fā)來說是一件惱人的事，但沒有遠(yuǎn)程shell來運(yùn)行系統(tǒng)是更讓人煩惱的事。Erlang有驕人的追蹤能力，一些工具是建立在這些能力上的，比如recon_trace。Erlang的內(nèi)省很好的改善了開發(fā)，同時也能更好的維護(hù)復(fù)雜的系統(tǒng)。

　　靜態(tài)鏈接

　　是的，同樣積極正面的一個東西，但如果用在期望運(yùn)行時間很長的系統(tǒng)上它就變得消極了。雖然沒有鏈接執(zhí)行確實(shí)會比較慢，但這卻給了Erlang在運(yùn)行系統(tǒng)上代碼替換方面的優(yōu)勢。很有必須說明一下，由于Erlang的調(diào)度和垃圾收集策略，許多這些速度權(quán)衡并不意味著Erlang在同樣的應(yīng)用中會比其它語言慢，特別是如果Erlang應(yīng)用是唯一一個仍在運(yùn)行的。

　　代碼組織

　　OTP框架為通用模式提供了庫。OTP不僅意味著更少的代碼和更好的抽象，同時也意味著更好的可讀性。隨著應(yīng)用的OTP標(biāo)準(zhǔn)，管理人員和工人（gen_server, gen_fsm, gen_event）意味著程序的新開發(fā)人員能夠通過進(jìn)程樹很好的工作，同時也表明他們之間是如何交互的。GO的channel，不可識別的goroutine和缺乏模式將goroutine分割成獨(dú)立的模塊會讓代碼變得更難寫。

　　GO能改變、應(yīng)該改變嗎？

　　Erlang已經(jīng)問世數(shù)十年了，而GO是新產(chǎn)品，那么GO能在這些領(lǐng)域得到改善嗎？有些地方是可以的，但由于語言設(shè)計本身缺乏容錯和低延遲，它在絕大地方都不能改善現(xiàn)狀。

　　這并不是說GO不好或者它設(shè)計得有誤。它的這些不同能讓其它像Erlang這樣的語言更好的解決不同的問題。

　　原文 blog.erlware.org

標(biāo)簽： 代碼

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。