有人問:

• 在 Quora 上，有個問題是比較 D/Rust/Go/Nim 等語言的表現(xiàn)，幾乎一致地認(rèn)為 Go 是最搓的，Rust 備受好評。各位看看何解?
• Of the Emerging Systems Languages Rust, D, Go and Nimrod, Which Is the Strongest Language and Why?

他們有一個觀點，能夠直接操作硬件的才被定義為系統(tǒng)級語言，而另外定義是適用于 web 后端或者分布式。Go 由于其 gc 而被直接否定。

北南(Twitter核心服務(wù)組后端程序員)：

其實go不管在國內(nèi)還是國外已經(jīng)很受待見了，國外google用的很多，uber也在用，國內(nèi)有著名的今日頭條，每日千億級的訪問妥妥的。多少語言終其一生都沒有這么大的應(yīng)用場景。而且go不能算system programming language了吧，我的理解是system programming language你總得能和c互動吧，或者題主說的直接操作硬件(我換個措辭，cgo是不建議在應(yīng)用開發(fā)中使用的，所以說現(xiàn)在的go是不鼓勵你和c互動的。雖然使用cgo是能夠和c互動的，但能不能和要不要是兩個概念，我建議是不要，使用cgo是得不償失的。這個很多文章都有討論，有興趣大家可以自己搜)

go最堅持最核心的理念是簡單和正交性(這也是我最想從go的設(shè)計中吸取經(jīng)驗的地方)，所有其他東西包括性能以及大家最津津樂道的并發(fā)性都向這兩點妥協(xié)。我看前面有個谷歌工程師的答主說它的目標(biāo)是適合大團(tuán)隊開發(fā)，能解決google以前在C++開發(fā)(我覺得這里的C++開發(fā)應(yīng)該是應(yīng)用開發(fā)，而不是題主說的system programming)中遇到的問題。這才是go出世的真正目的。

至于答主們所說的范型也好，錯誤返回也罷，這都不在go的最高優(yōu)先級上吧。你們說丑，人家也沒說要把自己弄的漂亮。官方說，你們可以用別的方式來優(yōu)雅的實現(xiàn)要用范型的地方。我是挺敬佩那幫大哥的，搞了這樣一個語言，明知被罵也敢發(fā)布，但我支持他們堅持自己的信仰。

Rust/D/Nim都是正經(jīng)(一直涼涼的)的系統(tǒng)編程語言，拿這哥仨出來和go比也沒啥意思。我覺得有志之士應(yīng)該拿 。net core出來和go比劃比劃。

應(yīng)回復(fù)里的兄弟要求，稍微說一下正交性(Orthogonality)

這個詞還挺時髦的，就是說每個模塊之間互相不影響，或者說互相不知道。改了一個不會影響另外一個。那為什么說go正交性好呢?除了go那些基本庫做的都比較簡單和職責(zé)明確以外，主要是go interface的設(shè)計。

做過go的都知道，你沒別的東西可以用啊。你只能讓interface在模塊之間傳來傳去。

如果我們用其他靜態(tài)類型語言，往往我們要調(diào)用什么其他模塊的方法，我們要使用對應(yīng)的類型，比如說其他模塊要傳入一個Class AAA with Inteface BBB，我們就要作出一個這樣的類型的對象實例給它。這期間難免要依賴AAA和BBB里的不少東西，至少我要知道有AAA和BBB的存在。

 

class MyClass extends AAA implements BBB { 
   int aaa（）{...} 
   int bbb（）{...} 
} 

go的話，你就照著其他模塊的要求，做一個和它interface長得一模一樣的就行。這個耦合就松了。

 

type MyClass interface {  
    aaa() int  ///AAA里要的方法 
    bbb() int  ///BBB里要的方法 
}  

所以模塊間不是用傳統(tǒng)的類型耦合，是靠長相耦合，你長得和我一樣，你就是我了，而且你都不需要知道你是長得和我像，咱倆就正交了。再比如說只要提供httpHandle函數(shù)的，就是個HttpHandler，它自己都不需要知道自己是個HttpHandler。

這樣做也是有得有失，仁者見仁智者見智吧，go正交性的目標(biāo)我同意，但是做法。。。我覺得還可以再考慮考慮。

雖然我覺得scala在后端才真是單刀在手，天下我有。不過要說誰是java之后的下一代后端當(dāng)家花旦，我投go一票。

luikore

Rust 和 Nim 確實好呀

Rust 可以說是 D 語言二代目, 沒有 D 里的一些經(jīng)驗主義設(shè)計, 而且更函數(shù)式, 作為 a better C++ 當(dāng)之無愧. Pattern matching, Block, Generic 這些東西, Go 有么? 不好的地方是集成 feature 略貪心, 指針那么多類型是有道理但是學(xué)習(xí)者容易被嚇跑.

Nim 不是函數(shù)式的, 但 Nim 支持衛(wèi)生宏, 可以做 AST 重寫, 可以自定編譯規(guī)則, 是靜態(tài)語言中的黑客語言有木有! 自定編譯規(guī)則甚至可以編譯出比 C 代碼還快的結(jié)果, 作為 a better C 當(dāng)之無愧. 人家 GC 可以手動步進(jìn)的啊, 想要什么 feature 自己加(list comprehension? 沒問題), 加個 const 就可以做編譯期計算了(想想 C++ 和 D 里復(fù)雜難以掌握的 template 和 static if 多蛋疼), 改寫 AST 的 pattern language 也是簡單易懂(想想 Java 的 annotation processing tool 怎么用的就蛋碎…), 更重要的一點: 沒有那么多哲學(xué)騎著你禁止你怎么怎么做, Go 能么?

人類思維有個巨大的缺點就是從眾定勢, 當(dāng)然社區(qū)大了開發(fā)者多了語言會更容易成熟和變得實用, 但如果更多人懂得多了解學(xué)習(xí), 理性比較而不是跟風(fēng), 現(xiàn)在的編程語言可以發(fā)展得更好.

布丁@kyhpudding

回@Irons Du, 不是為了反對他的答案，是因為基于這些問題，能解釋 Go 不受待見的其中一個原因：Go 面對的問題和整個解決思路跟 Google 軟件的規(guī)模相關(guān)，而這個規(guī)模是罕見的。20 億行源碼放在一個統(tǒng)一的代碼庫，全部主干提交，理論上代碼庫里任何兩點都可以互相調(diào)用，幾萬個工程師(我是其中一名豬隊友)在全球各個時區(qū)協(xié)同。Why Google Stores Billions of Lines of Code in a Single Repository. 這個設(shè)計前提導(dǎo)致了同樣被黑得很慘的 C++ Style Guide (The Philosophy of Google’s C++ Code) 和 Go 的一些看著很奇葩的設(shè)計點。

另外這個軟件規(guī)模是一個問題，不是什么值得炫耀的東西。Go 為解決這些問題的設(shè)計，并不一定適合其他場景。回答這個問題本身，這里也不是說 Go 有多好，只是可以分享一些「為什么」，很有趣的設(shè)計權(quán)衡，例如 Quora 原文提到的 Go 幾乎忽略了所有現(xiàn)代 PL 研究成果，但實際上這些成果在這個規(guī)模上還沒能很好地工作。關(guān)于 Go 為什么是(或不是)系統(tǒng)編程語言的問題，我可以另外寫一篇。

1：你能輕松知道哪些struct繼承(實現(xiàn))了哪些interface么?

能，Go guru. 2016-talks/slides.pdf at master · gophercon/2016-talks · GitHub 在超大軟件庫上一樣很順。顯式 implements 聲明上規(guī)模后會有問題，多余的依賴關(guān)系是其中之一，下面有關(guān)于依賴的更詳細(xì)討論。

2：你能輕松知道struct有哪些”成員函數(shù)”么?

能，godoc 啊

這兩點正好說明了 Go 極端重視工具的設(shè)計思路，工具能解決大代碼庫上源代碼級別無法解決的問題，比如全代碼庫索引、重構(gòu)，計算改動影響范圍觸發(fā)集成測試等等。這里面也必須有權(quán)衡，例如，要為這個規(guī)模寫編譯器和各種工具，你最好別搞復(fù)雜的類型系統(tǒng)，不然事情會很困難。

3：手動維護(hù)defer能比RAII輕松?

RAII 很難。C++ destructor + exception, 這里的 exception 包括處理 destructor 的異常安全和 destructor 自己真的需要拋異常的情況。還有如果在 destructor 里放了重型操作，比如 flush 硬盤，defer 至少讓你清楚地看到這種重操作會在哪里跑。這些問題當(dāng)然都可以用很仔細(xì)的設(shè)計避免，但是在有幾萬個豬隊友的時候，不要指望每個人都能做出好設(shè)計。

4：package只有一個層次

如果是指不能只 import 一個父節(jié)點而要顯式 import 所有葉子節(jié)點。這是用來控制 dependency 的，不必要的 dependency 在大軟件庫是個嚴(yán)重問題。Go 奇葩的 import 多余 package 直接編譯錯誤的規(guī)則也是這個目的。

5：訪問控制只能限定在package之外。

個人體驗，它省掉了很多語法規(guī)則，還工作得很好。有點不方便的是你看它 call 一個私有函數(shù)，但是在同一個文件里是找不到這個函數(shù)的定義的，它可能在同一個 package 的另一個文件里。這個是用工具補(bǔ)足的 —— 在內(nèi)部的 code search 工具里我沒感覺不方便，在 github 沒有交叉引用的情況下看代碼就比較郁悶。

6：基于源代碼的開發(fā)(復(fù)用)，這是否違背了以前書上說的實現(xiàn)隱藏(只暴露接口)?

沒，主要是因為 Google 統(tǒng)一代碼庫，Go 一開始壓根沒考慮二進(jìn)制庫發(fā)布的問題。這跟軟件工程的隱藏實現(xiàn)是兩回事。依賴版本管理問題同理，因為統(tǒng)一代碼庫+全主干提交，這個問題在 Google 是不存在的…… 當(dāng)然問題就是問題，現(xiàn)在外部使用越來越多他們也在逐步補(bǔ)鍋了。

7：推崇error作為返回值是不對的。另外(panic+recover)對比下C++在C之上添加的異常處理(+RAII)的類型安全

推薦一篇微軟 Midori 項目 (Rethinking the software stack) 語言 leader 的 Joe Duffy – The Error Model (超長)。error 功能不夠好，但 C++ 和 Java 的 exception 機(jī)制在上規(guī)模后也有無法解決的工程和性能的問題，Optional是好，但是語言就要變復(fù)雜，這里面有 tradeoff. 另外，「異常安全」是個看起來遵守規(guī)則寫就可以的簡單事情，但實際上非常困難，比如事務(wù)的回滾，文中也有專門描述。

Shisoft Architect

因為 Go 語言的確是最搓的

就連 Go 語言最引以為傲的并發(fā)模型， 在某些語言里也就是一個庫就能解決的事情(clojure/core.async)。

語言就要做好語言該做的事情。語言特性太弱，runtime 不夠輕量，沒辦法做 system language 也是很正常的事情。也怪不了寫 C/C++ 和 Rust 的人看不上它。

我第一次看到一個現(xiàn)代通用，宣稱自己是 static typing 的編程語言下的第三方容器庫清一色拿 string 做 key，interface{} 做 value 是很傻眼的。給我一種喜歡寫 go 的都是之前習(xí)慣寫 php 和 javascript 的錯覺。

Go 語言社區(qū)最大的問題在于自身語言特性弱還給開發(fā)人員強(qiáng)加設(shè)計哲學(xué)，并宣稱這種做法是絕對正確的，你們只要無腦去用就可以了。靜態(tài)語言里我沒見過哪個語言的 map 和 list 是內(nèi)置的，并且還會幫你隱藏后面的實現(xiàn)算法。你如果需要一個特定的數(shù)據(jù)結(jié)構(gòu)容器，只能去忍受一次次的類型轉(zhuǎn)換。然后就又有一群人說 interface{} 用的多是寫的人太搓。humm…那你告訴我這個項目(mijia/gopark)里滿天飛的 interface{} 按照 Go 語言的設(shè)計哲學(xué)怎么消掉保證安全性，并且還不會有運(yùn)行時的性能損失。

其他的。。。話說沒有 enum 嗎

所以 Go 語言也就是做做后端微服務(wù)之類勞動密集型的應(yīng)用，還沒到可以和 java 現(xiàn)在的核心應(yīng)用競爭的程度。

祭阿泣

幾個實際例子。

goroutine泄漏。goroutine雖然方便，但是粗心的開發(fā)者用爽了之后，會濫用goroutine，導(dǎo)致和內(nèi)存泄露類似的問題(再搞一個垃圾goroutine回收機(jī)制?2333)。

官方包bug。之前用cgo封了個很簡單的HttpClient給C調(diào)用，go1.5的gc在C程序中不完美，導(dǎo)致有時鏈接不會正常釋放，程序還會時不時hang在os.yield上。go1.6更新日志的第一句就是cgo完美支持gc，但是我試了一下這個問題依然存在。還有什么不支持低版本ld(去go源碼中注釋掉一行代碼，然后重新編譯go就能“支持”了)。

官方包文檔。http包，transport，client這些類如果想要自己訂制一些功能，那么最好要搞清楚什么類開了什么goroutine，是不是端口需要手動close，goroutine有沒有shutdown。這些文檔里沒有說。

風(fēng)格。我真的很不喜歡寫一句話就寫n句if err!=nil{…｝，而且寫完之后還要想盡辦法去構(gòu)造單元測試來覆蓋這個分支。如果你覺得這個地方實在是不會出現(xiàn)err，那么就用_來吃掉這個err吧，然而以后每個看代碼的人都會看到這個_，然后想想為什么這里可以吃掉這個err，浪費(fèi)時間不喜歡。太過于嚴(yán)謹(jǐn)，需要更折中一些，個人覺得。

王岳楠

在一家省分行用go每天處理二千萬條數(shù)據(jù)入數(shù)據(jù)倉庫做數(shù)據(jù)分析，后臺用oci連oracle，前臺web只用了gorilla的mux庫，三個月來系統(tǒng)很穩(wěn)定，數(shù)據(jù)處理速度及報表交互速度很快。做過一個與核心對接的交易查詢系統(tǒng)，使用cgo與核心中間件對接，也很穩(wěn)定，數(shù)據(jù)庫mysql。還用go做了一個預(yù)算管理、一個服務(wù)器資源監(jiān)控系統(tǒng)和一個基于activity的workflow，做完的感覺就是我今后很長時間還是會用go。以前做項目用過java，Python。Java的缺點是語法太啰嗦，虛擬機(jī)還得調(diào)優(yōu)。Python不能充分利用多核，部署也麻煩。golang優(yōu)點很明顯：語法像Python一樣靈活優(yōu)雅，后期運(yùn)維部署簡單方便到讓我感動(經(jīng)過python部署折磨后)，沒有泛型之類的語法我也基本把上述系統(tǒng)的業(yè)務(wù)邏輯都完成了，我不是個語言控，語言不必大而全，復(fù)雜了我也玩兒不轉(zhuǎn)，也不需要語法糖對別人炫耀(時間長了我也看不懂)，對于我來說就是把系統(tǒng)業(yè)務(wù)邏輯快速完成，開發(fā)部署越簡單越好，系統(tǒng)一定要穩(wěn)定。golang滿足了我一切要求，真的有它就go了。

Irons Du

1. 你能輕松知道哪些struct繼承(實現(xiàn))了哪些interface么?
2. 你能輕松知道struct有哪些”成員函數(shù)”么?
3. 手動維護(hù)defer能比RAII輕松?更安全?怕不怕順序問題?怕不怕寫露了?而且是函數(shù)作用域的。
4. package只有一個層次，容易出現(xiàn)沖突。
5. 訪問控制只能限定在package之外。而且沒有static 函數(shù)等等。
6. 基于源代碼的開發(fā)(復(fù)用)，這是否違背了以前書上說的實現(xiàn)隱藏(只暴露接口)?
7. 推崇error作為返回值是不對的。另外(panic+recover)對比下C++在C之上添加的異常處理(+RAII)的類型安全， defer 也沒有顯式的try catch直觀和精確控制。
8. go是入門簡單，學(xué)好難。難在多線程編程。Go能更容易寫出多線程程序。但對于一個需求明確的任務(wù)，我并不覺得通過仔細(xì)斟酌設(shè)計的C++多線程程序比Go差，反而更好，很多地方更容易控制。當(dāng)然這需要能力。但既然沒得能力，我相信同樣也寫不好Go的多線程程序。

ps，前[1-5]對于小項目問題不大。

冒泡

只說我個人對go的意見，由于用得不深可能有些說得不對的地方

語言設(shè)計雖然要有創(chuàng)新，但語法這種東西搞太多創(chuàng)新反而會提高學(xué)習(xí)成本，比如在C++和go中切換一陣子，常常寫錯string s和s string，當(dāng)然這是一個喜好問題，花點力氣轉(zhuǎn)過來也不是困難

語法過于封閉和霸道，譬如map、range這種可以作為一個庫或方法的都實現(xiàn)為關(guān)鍵字，當(dāng)然，你說這些常用，那沒啥問題，但是我們能不能對于自定義的結(jié)構(gòu)，定義它自身的hash、eq來作為map的key，以及能不能定義自己的方法讓它可以被range呢，貌似沒找到辦法，不是很確定，如果有請告訴我呀

非入侵接口是有些優(yōu)勢，但會帶來比較大的效率損耗，雖然1.7出來后整體速度提了一截，但用不用interface的比對還是差距比較大的，另外這個設(shè)計本身的一些缺陷網(wǎng)上也有文章專門敘述，略了

沒泛型，比如，怎么定義一個可以和自身比較的類型的通用接口呢，即類似Java中>這種，如果用interface的話，貌似不能限定“只能和自身類型”，那只好運(yùn)行時動態(tài)檢查?我因為這個問題，看了sort庫的代碼，發(fā)現(xiàn)是從另一個角度繞過的，而且sort這么搞只能有效支持類似數(shù)組的結(jié)構(gòu)了，那我想寫個通用紅黑樹怎么設(shè)計接口呢，感覺比較困難

錯誤處理很多人吐槽過了。。。其實我倒是沒那么強(qiáng)烈的意見，就是寫一些小腳本太啰嗦

cgo的性能，大部分語言的C擴(kuò)展很多時候是用來改寫核心模塊而提高效率，go卻不是，cgo的設(shè)計是有自己的苦衷，但能不能提供一種不走環(huán)境切換的選擇呢

曹東

每種語言都有適用場景，不太好同維度對比。

go的gc確實是一大痛點。我們的項目中，就單獨(dú)做了定制化的gc優(yōu)化，確實是一件頭痛的事，一點都不gopher。但，go很年輕，也一直在迭代，進(jìn)步也是大家有目共睹的。八月份馬上要放出1.7release了，在gc上做了進(jìn)一步優(yōu)化。

go的賣點：1，goroutine(同步方式編寫異步代碼，so easy);2，輕松高并發(fā);3，少即指數(shù)級的多(語法簡單，但組合出的變化卻很多)4，開發(fā)效率高;5，編譯速度快、部署簡單(以前靜態(tài)連接是一個賣點，后面版本開始支持動態(tài)鏈接庫后走偏了);6，親爹支持。

其實go的社區(qū)還是很活躍的，國內(nèi)我所知的，很多公司開始將后臺、中間件遷移到go了，像百度的BFE7層接入系統(tǒng)、360的長連接推送系統(tǒng)、美團(tuán)的廣告中間件、滴滴的認(rèn)證系統(tǒng)、七牛云平臺、鏈家、vmware、uber中國。。。名單會很長很長

姜太公

因為在做Docker相關(guān)的事情，整個Docker生態(tài)基本上都是Go語言的，也不得不跟著使用Go。有幾個方面確實覺得很不爽

首先是錯誤處理，由于沒有異常機(jī)制，只能寫大量的if err != nil。代碼里充斥著這種判斷。實際上很多時候我們并不需要出錯之后進(jìn)行恢復(fù)，處理不了，只想把錯誤往上拋。比如讀文件，用Python我可以這樣寫

 

with open('file') as f: 
    data = f.read() 

文件不存在怎么辦?io錯誤怎么辦?大多數(shù)時候我們沒辦法原地處理錯誤，只能繼續(xù)上拋，讓調(diào)用方處理。用Go怎么寫?

 

var f os.File 
if f, err := os.Open("file"); err != nil { 
    return err 
} 
var data []byte 
if data, err := ioutil.Read(f); err != nil { 
    return err 
} 

其次是出錯時候的錯誤信息，不想Java/Python，異常信息里包含了運(yùn)行棧，Go的error就是一個普通接口，通常只有一句簡單錯誤信息。看到錯誤日志里的信息，不去搜代碼你都不知道哪個地方出的錯。

還有坑爹的包管理，這個前面也有人吐槽了。強(qiáng)制的目錄結(jié)構(gòu)也挺坑爹的。當(dāng)初我想給自己的Go項目加一個自動構(gòu)建的腳本，我在項目里使用了godep，自帶所有的依賴，這樣別人從github clone代碼到本地之后運(yùn)行./build就能構(gòu)建了。解決同時clone之后build出錯!我過去一看，依賴倒是沒問題，項目本身的包找不到!Go要求代碼必須放在$GOPATH/src/下面，比如我的項目必須放在$GOPATH/src/http://github.com/xxxx/hello目錄下。

接口的實現(xiàn)方式，由于只要實現(xiàn)了所有的方法就算實現(xiàn)了接口，不用顯式聲明，所以光看代碼根本沒法找到到底實現(xiàn)了哪個/哪幾個接口。

黃川

個人覺得不是不受待見， 而是人自身的問題：

第一：

現(xiàn)在招聘GO語言的工作很少，從大環(huán)境來看就是這樣，七牛算一個，然并卵，我不會因為一份工作去七牛所在的地區(qū)工作。

第二：

現(xiàn)在Java還是大行其道，大的技術(shù)公司主要編程需要還都是java或者C++，現(xiàn)在又有node這種怪胎(不要覺得我碰node，為什么node這么火，還不是入門門檻低，前端都會寫，但是軟件工程，系統(tǒng)架構(gòu)有幾個人懂，能寫出好代碼才怪，寫點小工具或者小型網(wǎng)站還是馬馬馬虎虎的，畢竟快，讓我們寫后端的童鞋寫一個網(wǎng)站沒幾個月寫不出來，界面不會寫啊，讓我哭一會)，拉回來，一家公司想要轉(zhuǎn)新的語言，是多么大的風(fēng)險，沒有沖勁的領(lǐng)導(dǎo)不敢干這事，所以Go始終還是小眾語言的存在，但是隨著Docker的普及，慢慢地大家也開始關(guān)注GO了，這是好事，還有微服務(wù)的推廣，跨語言的業(yè)務(wù)開發(fā)極大的幫助了Go的推廣。但是現(xiàn)階段還是安心寫Java吧。

第三：

我們知道業(yè)務(wù)代碼再往下下就倒系統(tǒng)了，GO對系統(tǒng)API的調(diào)用做得很好，直接syscall調(diào)用，可以聯(lián)編C代碼，多好啊，但是你會么，或者說看這篇文章的人里面有幾個人自己研究過Linux或者Freebsd的底層接口，退一步，除了寫業(yè)務(wù)代碼之外沉下心研究過操作系統(tǒng)底層的有幾個?對于分布式原理的理解的有幾個?(吹牛逼的自己閉嘴，我說的分布式原理，不是別的網(wǎng)站里面看幾篇文章就說自己懂分布式)還有鎖，分布式鎖等概念，在并發(fā)編程里面都是需要注意的，有幾個人愿意花時間在這上面。

所以，不是Go不受待見，而是人自己固步自封，你必須承認(rèn)Go就是比java快，就是比PHP快，能做的事情更多，系統(tǒng)資源的使用更加淋漓盡致，雖然比不上C與C++，但是也算接近，而且編譯更快，自帶內(nèi)存管理，語法清晰。但是，你還是更喜歡把時間花在打游戲上，另外，喜歡就是喜歡，管別人待不待見Go呢。