有人問:

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

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

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

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

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

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

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

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

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

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

如果我們用其他靜態類型語言，往往我們要調用什么其他模塊的方法，我們要使用對應的類型，比如說其他模塊要傳入一個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里要的方法 
}  

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

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

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

luikore

Rust 和 Nim 確實好呀

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

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

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

布丁@kyhpudding

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

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

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

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

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

能，godoc 啊

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

3：手動維護defer能比RAII輕松?

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

4：package只有一個層次

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

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

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

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

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

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

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

Shisoft Architect

因為 Go 語言的確是最搓的

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

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

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

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

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

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

祭阿泣

幾個實際例子。

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

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

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

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

王岳楠

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

Irons Du

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

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

冒泡

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

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

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

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

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

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

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

曹東

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

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

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

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

姜太公

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

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

 

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

文件不存在怎么辦?io錯誤怎么辦?大多數時候我們沒辦法原地處理錯誤，只能繼續上拋，讓調用方處理。用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，異常信息里包含了運行棧，Go的error就是一個普通接口，通常只有一句簡單錯誤信息。看到錯誤日志里的信息，不去搜代碼你都不知道哪個地方出的錯。

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

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

黃川

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

第一：

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

第二：

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

第三：

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

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