Go 是一門非常不錯的編程語言，并且逐漸取代 Python 成為很多人的選語言。但它也有一些缺點(diǎn)讓很多開發(fā)者忍不住吐槽，比如它在函數(shù)式編程、通道 / 并行切片處理、內(nèi)存垃圾回收、錯誤處理等方面都有一些問題。本文作者將 Go 存在的“硬傷”設(shè)計記錄了下來，與大家分享、討論。

Go 是一門非常不錯的編程語言。然而，我在公司的 Slack 編程頻道中對 Go 的抱怨卻越來越多（猜到我是做啥了的吧？），因此我認(rèn)為有必要把這些吐槽寫下來并放在這里，這樣當(dāng)人們問我抱怨什么時，我給他們一個鏈接就行了。

先聲明一下，在過去的一年里，我大量地使用 Go 語言開發(fā)命令行應(yīng)用程序、scc、lc 和 API。 其中既有供客戶端調(diào)用的大規(guī)模 API，也有即將在 https://searchcode.com/ 使用的 語法高亮顯示器。

我這些批評全部是針對 Go 語言的。但是，我對使用過的每種語言都有不滿。 我非常贊同下面的話：

“世界上只有兩種語言：人們抱怨的語言和沒人使用的語言?！?—— Bjarne Stroustrup

1、不支持函數(shù)式編程

我并不是一個函數(shù)式編程狂熱者。 說到 Lisp 語言，我首先想到的是語言障礙。

這可能是 Go 語言大的痛點(diǎn)了。 與大部分人不同，我不希望 Go 支持泛型，因?yàn)樗鼤槎鄶?shù) Go 項(xiàng)目帶來不必要的復(fù)雜性。 我希望 Go 語言支持適用于內(nèi)置切片和 Map 的函數(shù)式方法。 切片和 Map 具有通用性，并且可以容納任何類型，從這個意義上講，它們已經(jīng)非常神奇。在 Go 語言中只有利用接口才能實(shí)現(xiàn)類似效果，但這樣一來將喪失安全性和速度。

例如，請考慮下面的問題。

給定兩個字符串切片，找出二者都包含的字符串，并將其放入新的切片以備后用。

existsBoth := []string{}for _, first := range firstSlice {for _, second := range secondSlice {if first == second {existsBoth = append(existsBoth, proxy)break}}}

上面是一個用 Go 語言實(shí)現(xiàn)的簡單方案。當(dāng)然還有其它方法，比如借助 Map 來減少運(yùn)行時間。這里我們假設(shè)內(nèi)存足夠用或者切片都不太大，同時假設(shè)優(yōu)化運(yùn)行時間帶來的復(fù)雜性遠(yuǎn)超收益，因此不值得優(yōu)化。作為對比，使用 Java 流和函數(shù)式編程把相同的邏輯重寫如下：

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

上面的代碼隱藏了算法的復(fù)雜性，但是，你更容易理解它實(shí)際做的事情。

與 Go 代碼相比，Java 代碼的意圖一目了然。 真正靈活之處在于，添加更多的過濾條件易如反掌。 如果使用 Go 語言添加下面例子中的過濾條件，我們需要在嵌套的 for 循環(huán)中再添加兩個 if 條件。

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

有些借助 go generate 命令的項(xiàng)目可以幫你實(shí)現(xiàn)上面的一些功能。但是，如果缺少良好的 IDE 支持，抽取循環(huán)中的語句作為單獨(dú)的方法是一件低效又麻煩的事情 。

2、通道 / 并行切片處理

Go 通道通常都很好用。 但它并不能提供無限的并發(fā)能力。它確實(shí)存在一些會導(dǎo)致永久阻塞的問題，但這些問題用競爭檢測器能很容易地解決。對于數(shù)量不確定或不知何時結(jié)束的流式數(shù)據(jù)，以及非 CPU 密集型的數(shù)據(jù)處理方法，Go 通道都是很好的選擇。

Go 通道不太適合并行處理大小已知的切片。

3、多線程編程、理論和實(shí)踐

幾乎在其它任何語言中，當(dāng)列表或切片很大時，為了充分利用所有 CPU 內(nèi)核，通常都會使用并行流、并行 Linq、Rayon、多處理或其它語法來遍歷列表。遍歷后的返回值是一個包含已處理元素的列表。 如果元素足夠多，或者處理元素的函數(shù)足夠復(fù)雜，多核系統(tǒng)會更高效。

但是在 Go 語言中，實(shí)現(xiàn)高效處理所需要做的事情卻并不顯而易見。

一種可能的解決方案是為切片中的每個元素都創(chuàng)建一個 Go 例程。 由于 Go 例程的開銷很低，因此從某種程度上來說這是一個有效的策略。

toProcess := []int{1,2,3,4,5,6,7,8,9}var wg sync.WaitGroupfor i, _ := range toProcess {wg.Add(1)go func(j int) {toProcess[j] = someSlowCalculation(toProcess[j])wg.Done()}(i)}wg.Wait()fmt.Println(toProcess)

上面的代碼會保持切片中元素的順序，但我們假設(shè)不必保持元素順序。

這段代碼的第一個問題是增加了一個 WaitGroup，并且必須要記得調(diào)用它的 Add 和 Done 方法。這增加了開發(fā)人員的工作量。如果弄錯了，這個程序不會產(chǎn)生正確的輸出，結(jié)果是要么輸出不確定，要么程序永不結(jié)束。此外，如果列表很長，你會為每個列表創(chuàng)建一個 Go 例程。正如我之前所說，這不是問題，因?yàn)?Go 能輕松搞定。問題在于，每個 Go 例程都會爭搶 CPU 時間片。因此，這不是執(zhí)行該任務(wù)的最有效方式。

你可能希望為每個 CPU 內(nèi)核創(chuàng)建一個 Go 例程，并讓這些例程選取列表并處理。創(chuàng)建 Go 例程的開銷很小，但是在一個非常緊湊的循環(huán)中創(chuàng)建它們會使開銷陡增。當(dāng)我開發(fā) scc 時就遇到了這種情況，因此我采用了每個 CPU 內(nèi)核對應(yīng)一個 Go 例程的策略。在 Go 語言中，要這樣做的話，你首先要創(chuàng)建一個通道，然后遍歷切片中的元素，使函數(shù)從該通道讀取數(shù)據(jù)，之后從另一個通道讀取。我們來看一下。

toProcess := []int{1,2,3,4,5,6,7,8,9}var input = make(chan int, len(toProcess))for i, _ := range toProcess {input <- i}close(input)var wg sync.WaitGroupfor i := 0; i < runtime.NumCPU(); i++ {wg.Add(1)go func(input chan int, output []int) {for j := range input {toProcess[j] = someSlowCalculation(toProcess[j])}wg.Done()}(input, toProcess)}wg.Wait()fmt.Println(toProcess)

上面的代碼創(chuàng)建了一個通道，然后遍歷切片，將索引值放入通道。 接下來我們?yōu)槊總€ CPU 內(nèi)核創(chuàng)建一個 Go 例程，操作系統(tǒng)會報告并處理相應(yīng)的輸入，然后等待，直到所有操作完成。這里有很多代碼需要理解。

然而，這種實(shí)現(xiàn)有待商榷。如果切片非常大，通道的緩沖區(qū)長度和切片大小相同，你可能不希望創(chuàng)建一個有這么大緩沖區(qū)的通道。因此，你應(yīng)該創(chuàng)建另一個 Go 例程來遍歷切片，并將切片中的值放入通道，完成后關(guān)閉通道。 但這樣一來代碼會變得冗長，因此我把它去掉了。我希望可以大概地闡明基本思路。

使用 Java 語言大致這樣實(shí)現(xiàn)：

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

通道和流并不等價。 使用隊列去仿寫 Go 代碼的邏輯更好一些，因?yàn)樗鼈兏哂锌杀刃裕覀兊哪康牟皇沁M(jìn)行 1 對 1 的比較。 我們的目標(biāo)是充分利用所有的 CPU 內(nèi)核處理切片或列表。

如果 someSlowCalucation 方法調(diào)用了網(wǎng)絡(luò)或其它非 CPU 密集型任務(wù)，這當(dāng)然不是問題。 在這種情況下，通道和 Go 例程都會表現(xiàn)得很好。

這個問題與問題＃1 有關(guān)。如果 Go 語言支持適用于切片 /Map 對象的函數(shù)式方法，那么就能實(shí)現(xiàn)這個功能。 但是，如果 Go 語言支持泛型，有人就可以把上面的功能封裝成像 Rust 的 Rayon 一樣的庫，讓每個人都從中受益，這就很令人討厭了（我不希望 Go 支持泛型）。

順便說一下，我認(rèn)為這個缺陷妨礙了 Go 語言在數(shù)據(jù)科學(xué)領(lǐng)域的成功，這也是為什么 Python 仍然是數(shù)據(jù)科學(xué)領(lǐng)域的王者。 Go 語言在數(shù)值操作方面缺乏表現(xiàn)力和能力，原因就是以上討論的這些。

4、垃圾回收器

Go 的垃圾回收器做得非常不錯。我開發(fā)的應(yīng)用程序通常都會因?yàn)樾掳姹镜母倪M(jìn)而變得更快。但是，它以低延遲為高優(yōu)先級。對于 API 和 UI 應(yīng)用來說，這個選擇完全可以接受。對于包含網(wǎng)絡(luò)調(diào)用的應(yīng)用，因?yàn)榫W(wǎng)絡(luò)調(diào)用往往會是瓶頸，所以它也沒問題。

我發(fā)現(xiàn)的問題是 Go 對 UI 應(yīng)用來講一點(diǎn)也不好（我不知道它有任何良好的支持）。如果你想要盡可能高的吞吐量，那這個選擇會讓你很受傷。這是我開發(fā) scc 時遇到的一個主要問題。scc 是一個 CPU 密集型的命令行工具。為了解決這個問題，我不得不在代碼里添加邏輯關(guān)閉 GC，直到達(dá)到某個閾值。但是我又不能簡單的禁用它，因?yàn)橛行┤蝿?wù)會很快耗盡內(nèi)存。

缺乏對 GC 的控制時常令人沮喪。你得學(xué)會適應(yīng)它，但是，有時候如果能做到這樣該有多好：“嘿，這些代碼確實(shí)需要盡可能快地運(yùn)行，所以如果你能在高吞吐模式運(yùn)行一會，那就太好了。”

我認(rèn)為這種情況在 Go 1.12 版本中有所改善，因?yàn)?GC 得到了進(jìn)一步的改進(jìn)。但僅僅是關(guān)閉和打開 GC 還不夠，我期望更多的控制。 如果有時間我會再進(jìn)行研究。

5、錯誤處理

我并不是唯一一個抱怨這個問題的人，但我不吐不快。

value, err := someFunc()if err != nil {// Do something here}err = someOtherFunc(value)if err != nil {// Do something here}

上面的代碼很乏味。 Go 甚至不會像有些人建議的那樣強(qiáng)制你處理錯誤。 你可以使用“_”顯式忽略它（這是否算作對它進(jìn)行了處理呢？），你還可以完全忽略它。比如上面的代碼可以重寫為：

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

很顯然，我顯式忽略了 someFunc 方法的返回。someOtherFunc（value）方法也可能返回錯誤值，但我完全忽略了它。 這里的錯誤都沒有得到處理。

說實(shí)話，我不知道如何解決這個問題。 我喜歡 Rust 中的“?” 運(yùn)算符，它可以幫助避免這種情況。V-Lang https://vlang.io/ 看起來也可能有一些有趣的解決方案。

另一個辦法是使用可選類型（Optional types）并去掉 nil，但這不會發(fā)生在 Go 語言里，即使是 Go 2.0 版本，因?yàn)樗鼤茐南蚝蠹嫒菪浴?/p>

結(jié) 語

Go 仍然是一種非常不錯的語言。如果你讓我寫一個 API，或者完成某個需要大量磁盤 / 網(wǎng)絡(luò)調(diào)用的任務(wù)，它依然是我的選?，F(xiàn)在我會用 Go 而非 Python 去完成很多一次性任務(wù)，數(shù)據(jù)合并任務(wù)是例外，因?yàn)楹瘮?shù)式編程的缺失使執(zhí)行效率難以達(dá)到要求。

與 Java 不同，Go 語言盡量遵循“最小驚喜“原則。比如可以這樣比較字兩個符串是否相等：stringA == stringB。但如果你這樣比較兩個切片，那么會產(chǎn)生編譯錯誤。這些都是很好的特性。

的確，二進(jìn)制文件還可以變的更?。ㄒ恍?編譯標(biāo)志和 upx 可以解決這個問題），我希望它在某些方面變得更快，GOPATH 雖然不是很好，但也沒有人們想得那么糟糕，默認(rèn)的單元測試框架缺少很多功能，模擬（mocking）有點(diǎn)讓人痛苦......

它仍然是我使用過的效率較高的語言之一。我會繼續(xù)使用它，雖然我希望 https://vlang.io/ 能最終發(fā)布，并解決我的很多抱怨。V 語言或 Go 2.0，Nim 或 Rust?，F(xiàn)在有很多很酷的新語言可以使用，我們開發(fā)人員真的要被寵壞了。

本文標(biāo)題：Go語言很好很強(qiáng)大，但我有幾個問題想吐槽
標(biāo)題URL：http://jinyejixie.com/news7/98207.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、網(wǎng)站排名、網(wǎng)站導(dǎo)航、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計公司、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)