Go語言的設(shè)計上存在四大“硬傷”

Go語言為何不受待見？事實上，Go仍然是一種相當不錯的語言，并且逐漸取代Python成為很多人的首選語言。但是其卻有一些問題，使得開發(fā)速度大受影響。本文就跟隨作者一起解讀下Go中那些“硬傷”設(shè)計。

Go作為一種編程語言來說是相當體面的，然而，我在公司Slack（譯者注：一種團隊協(xié)作工具）的編程頻道上對它的抱怨卻越來越多（猜到我是做啥了的吧？）。我想我還是把這些抱怨寫下來放在這里，這樣當人們問我到底抱怨什么時，我就可以給他們一個鏈接，讓他們直接到這里來看。

過去一年左右的時間我都一直在大量地使用Go語言來編程，寫一些命令行應(yīng)用程序、scc（https://github.com/boyter/scc/）、lc（https://github.com/boyter/lc/）和一些API等等。

其中包括一個供客戶端調(diào)用代碼高亮插件（https://github.com/boyter/searchcode-server-highlighter）的大規(guī)模API，這個代碼高亮插件很快將會在https://searchcode.com/網(wǎng)站中使用。

我在這里的批評是專門針對Go編程語言的。然而，我對我使用的每種編程語言都有抱怨。這里我引用一下C++編程語言之父Bjarne Stroustrup說過的一句話：

“世界上只有兩種編程語言：一種是人們抱怨的語言，另一種是沒人使用的語言。”

——Bjarne Stroustrup

缺乏函數(shù)式編程

我不是一個函數(shù)式編程的狂熱分子。Lisp語言讓我首先想到的是語言障礙，這可能是我使用Go語言編程時最痛苦的地方。

和大多數(shù)開發(fā)者不一樣，我不想要泛型，我認為這只會給大多數(shù)Go項目增加不必要的復(fù)雜性。我想要的是一些可以應(yīng)用于內(nèi)置的Slice（切片）和Map類型之上的函數(shù)方法。Slice和Map這兩種類型都可以容納任何類型，而且是泛型的，這種在某種意義上很神奇。然而Go的泛型不使用接口的話，就無法實現(xiàn)自己，這樣就損失了所有的安全性和性能。

舉個例子，考慮下面的需求。

給定兩個字符串片斷，找出這兩段字符串片斷中都包含的相同的子字符串，并將其放入一個新的字符串片斷中，以便我們稍后處理它。

existsBoth:=[]string{}for_,first:=rangefirstSlice{for_,second:=rangesecondSlice{iffirst==second{existsBoth=append(existsBoth,proxy)break}}}

上面的Go語言的解決方法很簡單。但我們還有其他方法，如使用Map來解決這個問題，使用Map可以減少運行時間，但是如果我們的內(nèi)存容量有限，或者我們沒有很大的片斷需要處理，那么額外的運行時間并不足以抵消它帶來的復(fù)雜性。

讓我們將其與Java中使用Stream和函數(shù)編程來實現(xiàn)相同邏輯的代碼比較一下。

varexistsBoth=firstList.stream().filter(x->secondList.contains(x)).collect(Collectors.toList());

上面的代碼確實將算法的復(fù)雜性隱藏起來，從代碼上看清楚要實現(xiàn)的邏輯容易得多。

與實現(xiàn)同樣功能的Go代碼相比，上面的代碼的意圖是顯而易見的，真正的簡潔之處是添加額外的過濾器也變得非常簡單。而如果用Go語言實現(xiàn)像下面的示例一樣添加額外的過濾器，我們就必須在已經(jīng)嵌套的for循環(huán)中再添加兩個if條件。

varexistsBoth=firstList.stream().filter(x->secondList.contains(x)).filter(x->x.startsWith(needle)).filter(x->x.length()>=5).collect(Collectors.toList());

有一些使用Go Generate的項目可以為你做到上面所說的，但是如果沒有好的IDE支持的話，將上面的循環(huán)提取到它自己的方法中會非常笨重，而且會帶來更多的麻煩。

通道（channel）/并行切片（Slice）處理

Go的通道（channel）通常非常簡潔。雖然它們存在一些問題會導致它永久阻塞，但它們并不打算提供安全的并發(fā)性，因為通過競爭檢測機制可以很容易地擺脫這些問題。對于一個不知道有多少個值或何時結(jié)束的流，或者如果處理這些值的方法不受CPU的制約，那么通道是一個很好的選擇。

通道不太擅長的是處理那些預(yù)先知道大小并希望并行處理的切片(Slice)。

并行處理在幾乎所有其他語言中都很常見，通常發(fā)生在你有一個大的列表或切片，使用并行流、并行LINQ（語言集成查詢）、Rayon（一種數(shù)據(jù)并行庫）、多進程或其他一些語法，使用所有可用的CPU，對該列表/切片進行迭代處理時。你將它們應(yīng)用到你的列表上，然后返回處理好的元素列表。如果你的列表有太多的元素，或者你正在使用的函數(shù)太復(fù)雜，使用一個多核系統(tǒng)應(yīng)該也可以更快地完成。

然而，在Go語言中，你需要怎么實現(xiàn)它并不明確。

一種可能的解決方法是為切片中的每個元素生成一個goroutine。因為goroutine的開銷很低，所以在某種程度上，這是一個有效的策略。

toProcess:=[]int{1,2,3,4,5,6,7,8,9}varwgsync.WaitGroupfori,_:=rangetoProcess{wg.Add(1)gofunc(jint){toProcess[j]=someSlowCalculation(toProcess[j])wg.Done()}(i)}wg.Wait()fmt.Println(toProcess)

上面的代碼會保持切片中元素的順序，但是我們的例子并不要求實現(xiàn)這點。

上面的問題首先是添加一個waitgroup，并且必須記住遞增并調(diào)用它。這對開發(fā)人員開說是額外負擔。如果弄錯了，這個程序?qū)⒉粫a(chǎn)生正確的輸出，可能是不確定的結(jié)果，也可能永遠不會執(zhí)行完成。

另外，如果你的列表很長，你要為列表中每個單獨的元素生成一個goroutine。正如我之前所說，這本身不是一個問題，因為Go語言能毫無問題地做到這一點。但問題是，每一個goroutine都要為使用CPU的時間片而競爭。因此這不是執(zhí)行此任務(wù)的最有效方法。

你可能想做的是為每個CPU生成一個goroutine，并讓它們依次挑選處理它的列表。增加一個goroutine的開銷很小，但是對于一個迭代次數(shù)很多的循環(huán)來說，這個開銷并不算小。當我在為scc項目工作時，我遇到了這個問題，它在每個CPU的內(nèi)核上創(chuàng)建了一個goroutine。如果要完全用Go語言的方式來解決這個問題，你就需要創(chuàng)建一個通道，然后循環(huán)你的每個切片元素，讓你的函數(shù)從該通道讀取，然后再從另一個通道讀取。

讓我們看看代碼。

toProcess:=[]int{1,2,3,4,5,6,7,8,9}varinput=make(chanint,len(toProcess))fori,_:=rangetoProcess{input<-?i}close(input)var?wg?sync.WaitGroupfor?i?:=?0;?i?

上面的代碼先是創(chuàng)建了一個通道，循環(huán)我們的切片并將每個值放入其中。接著，為每個CPU內(nèi)核創(chuàng)建一個goroutine來處理輸入的值，然后等待它全部完成。要消化的代碼很多。

這不是一個你應(yīng)該怎么做的問題，因為如果你的切片非常大，你可能不想有一個具有相同長度的緩沖區(qū)的通道，所以你實際上應(yīng)該創(chuàng)建另一個goroutine來循環(huán)切片，并將這些值放入通道。當處理完成后，它關(guān)閉通道。我已經(jīng)刪除了這個代碼，因為它使代碼變得更長，而且我已經(jīng)基本上知道怎么做了。

Java的做法和上面大致相同。

varfirstList=List.of(1,2,3,4,5,6,7,8,9);firstList=firstList.parallelStream().map(this::someSlowCalculation).collect(Collectors.toList());

是的，Go語言的通道（channel）和Java中的流（stream）并不是一回事，通道更接近于Java中的隊列(queue)，但我們這里的目的不是1對1的對比。我們想要的是使用我們所有的CPU內(nèi)核來處理一個切片/列表。

當然，如果某個slowcaluation實際上是一個在網(wǎng)絡(luò)上調(diào)用的方法，或者是其他一些需要大量CPU的方法，那么這就不是一個問題。在這種情況下，通道和goroutine都很出色。

這一問題與缺乏函數(shù)式編程有關(guān)。如果Go語言在slice/map對象之上有函數(shù)方法，那么添加這個功能是可能的。這也很煩人，因為如果Go支持泛型的話，就會有人可以把上面談到的寫成一個函數(shù)庫，就像Rust的Rayon一樣，每個人都會受益。

順便說一句，我認為這一點阻礙了Go語言在數(shù)據(jù)科學領(lǐng)域的任何成功，因此，為什么Python仍然是那里的王者。而Go語言在數(shù)字操作中缺乏表現(xiàn)力和力量——以上就是原因。

垃圾回收（GC）

Go語言的垃圾回收機制非?？煽?。每次Go語言版本更新，我都發(fā)現(xiàn)我的應(yīng)用程序變得更快了，原因通常是因為GC的改進。將延遲的優(yōu)先級置于所有其它要求之上，對于API和UI來說，是一個完全可以接受的選擇。同樣地它也適用于任何有網(wǎng)絡(luò)呼叫的情況，這些呼叫也會成為瓶頸。

關(guān)鍵是Go語言對UI功能的實現(xiàn)沒有任何好處（據(jù)我所知沒有合適的綁定），當你需要盡可能大的吞吐量時，這個選擇確實會傷害你。我在處理scc項目時遇到了一個大問題，scc是一個命令行應(yīng)用程序，對CPU的要求很高。這是個問題，我添加了一個邏輯來關(guān)閉內(nèi)存回收機制，直到內(nèi)存使用量達到閾值。但是，我不能禁用它，因為程序在某些情況下工作時很快就會耗盡內(nèi)存。

對GC缺乏控制有時令人沮喪。你學會了接受它，但有時你會說“嘿，這里的代碼真的需要盡可能快的運行，所以如果能切換到高吞吐量模式一段時間，那就太好了?！?/p>

我認為隨著Go語言的1.12版本的發(fā)布，這一點變得越來越不可能了，在這個版本中，GC看起來再次得到了改進，但是僅僅關(guān)閉和打開GC并不是我想要的控制。有時間的話我會再次深入了解一下。

錯誤處理

我不是唯一一個對這點有抱怨的人，但我必須寫出來。

value,err:=someFunc()iferr!=nil{//Dosomethinghere}err=someOtherFunc(value)iferr!=nil{//Dosomethinghere}

上面的代碼看起來相當乏味。Go語言甚至不強制你處理大家建議的錯誤。你可以顯式忽略它（這是否算作處理它？），你甚至可以完全忽略它。例如，我可以像這樣重寫上面的內(nèi)容：

value,_:=someFunc()someOtherFunc(value)

你很容易發(fā)現(xiàn)我省略了somefunc返回的內(nèi)容，但是someotherfunc（value）同時也可以返回錯誤，而我卻完全忽略了這個錯誤，對它不作任何處理。

老實說，我不知道有這里有什么解決辦法。不過我喜歡Rust言語的問號(?)操作符，它可以避免這個問題。另外V-Lang（https://vlang.io/）看起來也可能有一些有趣的解決方案。

另一個想法是可選類型（Optional Type）和刪除nil，但是這些在Go語言的2.0版本中是永遠不會出現(xiàn)的，因為它會破壞向后兼容性。

總結(jié)

總的來講，Go仍然是一種相當不錯的語言。如果你要我要寫一個API，或者一些需要快速進行大量磁盤/網(wǎng)絡(luò)調(diào)用的應(yīng)用，它仍然是我的第一選擇。事實上，我正處在這樣一個階段：Go已經(jīng)取代Python，成為我要完成的大量的一次性任務(wù)的首選語言。數(shù)據(jù)合并任務(wù)除外，因為缺乏函數(shù)式編程仍然是一件痛苦的事情，這使得開發(fā)速度大受影響。

對諸如像字符串stringA == stringB和編譯錯誤的比較，你會發(fā)現(xiàn)Go語言的切片用在這里非常合適。它不像我在上面用來比較的Java語言那樣經(jīng)常有出人意料的結(jié)果。

Go的二進制文件的大小可以更?。ㄒ恍┚幾g開關(guān)和upx（可執(zhí)行文件壓縮工具）可以解決這個問題），我希望它在某些方面運行得更快一些，GOPATH不是很好，但也沒有每個人所說的那么糟糕，默認的單元測試框架缺少很多功能，Mocking有點痛苦等等。

Go仍然是我使用過的一種更有效的語言。我會繼續(xù)使用它，盡管我希望https://vlang.io/最終能夠發(fā)布并且解決我的許多投訴的問題。它可能Go 2.0版，可能是Nim，也可能是Rust?，F(xiàn)在有很多很酷的新語言可以玩。我們的開發(fā)人員真的被寵壞了。