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

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

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

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

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

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

——Bjarne Stroustrup

缺乏函數(shù)式編程

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

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

舉個(gè)例子，考慮下面的需求。

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

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

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

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

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

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

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

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

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

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

Go的通道（channel）通常非常簡(jiǎn)潔。雖然它們存在一些問題會(huì)導(dǎo)致它永久阻塞，但它們并不打算提供安全的并發(fā)性，因?yàn)橥ㄟ^競(jìng)爭(zhēng)檢測(cè)機(jī)制可以很容易地?cái)[脫這些問題。對(duì)于一個(gè)不知道有多少個(gè)值或何時(shí)結(jié)束的流，或者如果處理這些值的方法不受CPU的制約，那么通道是一個(gè)很好的選擇。

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

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

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

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

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)

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

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

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

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

讓我們看看代碼。

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

這不是一個(gè)你應(yīng)該怎么做的問題，因?yàn)槿绻愕那衅浅４螅憧赡懿幌胗幸粋€(gè)具有相同長(zhǎng)度的緩沖區(qū)的通道，所以你實(shí)際上應(yīng)該創(chuàng)建另一個(gè)goroutine來循環(huán)切片，并將這些值放入通道。當(dāng)處理完成后，它關(guān)閉通道。我已經(jīng)刪除了這個(gè)代碼，因?yàn)樗勾a變得更長(zhǎ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中的隊(duì)列(queue)，但我們這里的目的不是1對(duì)1的對(duì)比。我們想要的是使用我們所有的CPU內(nèi)核來處理一個(gè)切片/列表。

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

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

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

垃圾回收（GC）

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

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

對(duì)GC缺乏控制有時(shí)令人沮喪。你學(xué)會(huì)了接受它，但有時(shí)你會(huì)說“嘿，這里的代碼真的需要盡可能快的運(yùn)行，所以如果能切換到高吞吐量模式一段時(shí)間，那就太好了。”

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

錯(cuò)誤處理

我不是唯一一個(gè)對(duì)這點(diǎn)有抱怨的人，但我必須寫出來。

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

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

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

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

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

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

總結(jié)

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

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

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

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