有人問:

• 在 Quora 上，有個(gè)問題是比較 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?

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

luikore

Rust 和 Nim 確實(shí)好呀

Rust 可以說是 D 語言二代目, 沒有 D 里的一些經(jīng)驗(yàn)主義設(shè)計(jì), 而且更函數(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 可以手動(dòng)步進(jìn)的啊, 想要什么 feature 自己加(list comprehension? 沒問題), 加個(gè) const 就可以做編譯期計(jì)算了(想想 C++ 和 D 里復(fù)雜難以掌握的 template 和 static if 多蛋疼), 改寫 AST 的 pattern language 也是簡單易懂(想想 Java 的 annotation processing tool 怎么用的就蛋碎…), 更重要的一點(diǎn): 沒有那么多哲學(xué)騎著你禁止你怎么怎么做, Go 能么?

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

布丁@kyhpudding

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

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

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

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

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

能，godoc 啊

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

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

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

4：package只有一個(gè)層次

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

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

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

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

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

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

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

Shisoft Architect

因?yàn)?Go 語言的確是最搓的

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

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

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

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

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

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

祭阿泣

幾個(gè)實(shí)際例子。

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

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

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

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

王岳楠

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

Irons Du

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

ps，前[1-5]對于小項(xiàng)目問題不大。

冒泡

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

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

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

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

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

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

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

曹東

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

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

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

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

姜太公

因?yàn)樵谧鯠ocker相關(guān)的事情，整個(gè)Docker生態(tài)基本上都是Go語言的，也不得不跟著使用Go。有幾個(gè)方面確實(shí)覺得很不爽

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

 

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

文件不存在怎么辦?io錯(cuò)誤怎么辦?大多數(shù)時(shí)候我們沒辦法原地處理錯(cuò)誤，只能繼續(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 
} 

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

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

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

黃川

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

第一：

現(xiàn)在招聘GO語言的工作很少，從大環(huán)境來看就是這樣，七牛算一個(gè)，然并卵，我不會(huì)因?yàn)橐环莨ぷ魅テ吲Ｋ诘牡貐^(qū)工作。

第二：

現(xiàn)在Java還是大行其道，大的技術(shù)公司主要編程需要還都是java或者C++，現(xiàn)在又有node這種怪胎(不要覺得我碰node，為什么node這么火，還不是入門門檻低，前端都會(huì)寫，但是軟件工程，系統(tǒng)架構(gòu)有幾個(gè)人懂，能寫出好代碼才怪，寫點(diǎn)小工具或者小型網(wǎng)站還是馬馬馬虎虎的，畢竟快，讓我們寫后端的童鞋寫一個(gè)網(wǎng)站沒幾個(gè)月寫不出來，界面不會(huì)寫啊，讓我哭一會(huì))，拉回來，一家公司想要轉(zhuǎn)新的語言，是多么大的風(fēng)險(xiǎn)，沒有沖勁的領(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代碼，多好啊，但是你會(huì)么，或者說看這篇文章的人里面有幾個(gè)人自己研究過Linux或者Freebsd的底層接口，退一步，除了寫業(yè)務(wù)代碼之外沉下心研究過操作系統(tǒng)底層的有幾個(gè)?對于分布式原理的理解的有幾個(gè)?(吹牛逼的自己閉嘴，我說的分布式原理，不是別的網(wǎng)站里面看幾篇文章就說自己懂分布式)還有鎖，分布式鎖等概念，在并發(fā)編程里面都是需要注意的，有幾個(gè)人愿意花時(shí)間在這上面。

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