建站
咨詢
售后
建站咨詢
新聞中心
有人問(wèn):
站在用戶的角度思考問(wèn)題，與客戶深入溝通，找到海陽(yáng)網(wǎng)站設(shè)計(jì)與海陽(yáng)網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊(cè)、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋海陽(yáng)地區(qū)。
- 在 Quora 上，有個(gè)問(wèn)題是比較 D/Rust/Go/Nim 等語(yǔ)言的表現(xiàn)，幾乎一致地認(rèn)為 Go 是最搓的，Rust 備受好評(píng)。各位看看何解?
- Of the Emerging Systems Languages Rust, D, Go and Nimrod, Which Is the Strongest Language and Why?
他們有一個(gè)觀點(diǎn)，能夠直接操作硬件的才被定義為系統(tǒng)級(jí)語(yǔ)言，而另外定義是適用于 web 后端或者分布式。Go 由于其 gc 而被直接否定。
北南(Twitter核心服務(wù)組后端程序員)：
其實(shí)go不管在國(guó)內(nèi)還是國(guó)外已經(jīng)很受待見了，國(guó)外google用的很多，uber也在用，國(guó)內(nèi)有著名的今日頭條，每日千億級(jí)的訪問(wèn)妥妥的。多少語(yǔ)言終其一生都沒(méi)有這么大的應(yīng)用場(chǎng)景。而且go不能算system programming language了吧，我的理解是system programming language你總得能和c互動(dòng)吧，或者題主說(shuō)的直接操作硬件(我換個(gè)措辭，cgo是不建議在應(yīng)用開發(fā)中使用的，所以說(shuō)現(xiàn)在的go是不鼓勵(lì)你和c互動(dòng)的。雖然使用cgo是能夠和c互動(dòng)的，但能不能和要不要是兩個(gè)概念，我建議是不要，使用cgo是得不償失的。這個(gè)很多文章都有討論，有興趣大家可以自己搜)
go最堅(jiān)持最核心的理念是簡(jiǎn)單和正交性(這也是我最想從go的設(shè)計(jì)中吸取經(jīng)驗(yàn)的地方)，所有其他東西包括性能以及大家最津津樂(lè)道的并發(fā)性都向這兩點(diǎn)妥協(xié)。我看前面有個(gè)谷歌工程師的答主說(shuō)它的目標(biāo)是適合大團(tuán)隊(duì)開發(fā)，能解決google以前在C++開發(fā)(我覺(jué)得這里的C++開發(fā)應(yīng)該是應(yīng)用開發(fā)，而不是題主說(shuō)的system programming)中遇到的問(wèn)題。這才是go出世的真正目的。
至于答主們所說(shuō)的范型也好，錯(cuò)誤返回也罷，這都不在go的最高優(yōu)先級(jí)上吧。你們說(shuō)丑，人家也沒(méi)說(shuō)要把自己弄的漂亮。官方說(shuō)，你們可以用別的方式來(lái)優(yōu)雅的實(shí)現(xiàn)要用范型的地方。我是挺敬佩那幫大哥的，搞了這樣一個(gè)語(yǔ)言，明知被罵也敢發(fā)布，但我支持他們堅(jiān)持自己的信仰。
Rust/D/Nim都是正經(jīng)(一直涼涼的)的系統(tǒng)編程語(yǔ)言，拿這哥仨出來(lái)和go比也沒(méi)啥意思。我覺(jué)得有志之士應(yīng)該拿 。net core出來(lái)和go比劃比劃。
應(yīng)回復(fù)里的兄弟要求，稍微說(shuō)一下正交性(Orthogonality)
這個(gè)詞還挺時(shí)髦的，就是說(shuō)每個(gè)模塊之間互相不影響，或者說(shuō)互相不知道。改了一個(gè)不會(huì)影響另外一個(gè)。那為什么說(shuō)go正交性好呢?除了go那些基本庫(kù)做的都比較簡(jiǎn)單和職責(zé)明確以外，主要是go interface的設(shè)計(jì)。
做過(guò)go的都知道，你沒(méi)別的東西可以用啊。你只能讓interface在模塊之間傳來(lái)傳去。
如果我們用其他靜態(tài)類型語(yǔ)言，往往我們要調(diào)用什么其他模塊的方法，我們要使用對(duì)應(yīng)的類型，比如說(shuō)其他模塊要傳入一個(gè)Class AAA with Inteface BBB，我們就要作出一個(gè)這樣的類型的對(duì)象實(shí)例給它。這期間難免要依賴AAA和BBB里的不少東西，至少我要知道有AAA和BBB的存在。
- class MyClass extends AAA implements BBB {
- int aaa（）{...}
- int bbb（）{...}
- }
go的話，你就照著其他模塊的要求，做一個(gè)和它interface長(zhǎng)得一模一樣的就行。這個(gè)耦合就松了。
- type MyClass interface {
- aaa() int ///AAA里要的方法
- bbb() int ///BBB里要的方法
- }
所以模塊間不是用傳統(tǒng)的類型耦合，是靠長(zhǎng)相耦合，你長(zhǎng)得和我一樣，你就是我了，而且你都不需要知道你是長(zhǎng)得和我像，咱倆就正交了。再比如說(shuō)只要提供httpHandle函數(shù)的，就是個(gè)HttpHandler，它自己都不需要知道自己是個(gè)HttpHandler。
這樣做也是有得有失，仁者見仁智者見智吧，go正交性的目標(biāo)我同意，但是做法。我覺(jué)得還可以再考慮考慮。
雖然我覺(jué)得scala在后端才真是單刀在手，天下我有。不過(guò)要說(shuō)誰(shuí)是java之后的下一代后端當(dāng)家花旦，我投go一票。
luikore
Rust 和 Nim 確實(shí)好呀
Rust 可以說(shuō)是 D 語(yǔ)言二代目, 沒(méi)有 D 里的一些經(jīng)驗(yàn)主義設(shè)計(jì), 而且更函數(shù)式, 作為 a better C++ 當(dāng)之無(wú)愧. Pattern matching, Block, Generic 這些東西, Go 有么? 不好的地方是集成 feature 略貪心, 指針那么多類型是有道理但是學(xué)習(xí)者容易被嚇跑.
Nim 不是函數(shù)式的, 但 Nim 支持衛(wèi)生宏, 可以做 AST 重寫, 可以自定編譯規(guī)則, 是靜態(tài)語(yǔ)言中的黑客語(yǔ)言有木有! 自定編譯規(guī)則甚至可以編譯出比 C 代碼還快的結(jié)果, 作為 a better C 當(dāng)之無(wú)愧. 人家 GC 可以手動(dòng)步進(jìn)的啊, 想要什么 feature 自己加(list comprehension? 沒(méi)問(wèn)題), 加個(gè) const 就可以做編譯期計(jì)算了(想想 C++ 和 D 里復(fù)雜難以掌握的 template 和 static if 多蛋疼), 改寫 AST 的 pattern language 也是簡(jiǎn)單易懂(想想 Java 的 annotation processing tool 怎么用的就蛋碎…), 更重要的一點(diǎn): 沒(méi)有那么多哲學(xué)騎著你禁止你怎么怎么做, Go 能么?
人類思維有個(gè)巨大的缺點(diǎn)就是從眾定勢(shì), 當(dāng)然社區(qū)大了開發(fā)者多了語(yǔ)言會(huì)更容易成熟和變得實(shí)用, 但如果更多人懂得多了解學(xué)習(xí), 理性比較而不是跟風(fēng), 現(xiàn)在的編程語(yǔ)言可以發(fā)展得更好.
布丁@kyhpudding
回@Irons Du, 不是為了反對(duì)他的答案，是因?yàn)榛谶@些問(wèn)題，能解釋 Go 不受待見的其中一個(gè)原因：Go 面對(duì)的問(wèn)題和整個(gè)解決思路跟 Google 軟件的規(guī)模相關(guān)，而這個(gè)規(guī)模是罕見的。20 億行源碼放在一個(gè)統(tǒng)一的代碼庫(kù)，全部主干提交，理論上代碼庫(kù)里任何兩點(diǎn)都可以互相調(diào)用，幾萬(wàn)個(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è)問(wèn)題，不是什么值得炫耀的東西。Go 為解決這些問(wèn)題的設(shè)計(jì)，并不一定適合其他場(chǎng)景?；卮疬@個(gè)問(wèn)題本身，這里也不是說(shuō) Go 有多好，只是可以分享一些「為什么」，很有趣的設(shè)計(jì)權(quán)衡，例如 Quora 原文提到的 Go 幾乎忽略了所有現(xiàn)代 PL 研究成果，但實(shí)際上這些成果在這個(gè)規(guī)模上還沒(méi)能很好地工作。關(guān)于 Go 為什么是(或不是)系統(tǒng)編程語(yǔ)言的問(wèn)題，我可以另外寫一篇。
1：你能輕松知道哪些struct繼承(實(shí)現(xiàn))了哪些interface么?
能，Go guru. 2016-talks/slides.pdf at master · gophercon/2016-talks · GitHub 在超大軟件庫(kù)上一樣很順。顯式 implements 聲明上規(guī)模后會(huì)有問(wèn)題，多余的依賴關(guān)系是其中之一，下面有關(guān)于依賴的更詳細(xì)討論。
2：你能輕松知道struct有哪些”成員函數(shù)”么?
能，godoc 啊
這兩點(diǎn)正好說(shuō)明了 Go 極端重視工具的設(shè)計(jì)思路，工具能解決大代碼庫(kù)上源代碼級(jí)別無(wú)法解決的問(wèn)題，比如全代碼庫(kù)索引、重構(gòu)，計(jì)算改動(dòng)影響范圍觸發(fā)集成測(cè)試等等。這里面也必須有權(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ì)在哪里跑。這些問(wèn)題當(dāng)然都可以用很仔細(xì)的設(shè)計(jì)避免，但是在有幾萬(wàn)個(gè)豬隊(duì)友的時(shí)候，不要指望每個(gè)人都能做出好設(shè)計(jì)。
4：package只有一個(gè)層次
如果是指不能只 import 一個(gè)父節(jié)點(diǎn)而要顯式 import 所有葉子節(jié)點(diǎn)。這是用來(lái)控制 dependency 的，不必要的 dependency 在大軟件庫(kù)是個(gè)嚴(yán)重問(wèn)題。Go 奇葩的 import 多余 package 直接編譯錯(cuò)誤的規(guī)則也是這個(gè)目的。
5：訪問(wèn)控制只能限定在package之外。
個(gè)人體驗(yàn)，它省掉了很多語(yǔ)法規(guī)則，還工作得很好。有點(diǎn)不方便的是你看它 call 一個(gè)私有函數(shù)，但是在同一個(gè)文件里是找不到這個(gè)函數(shù)的定義的，它可能在同一個(gè) package 的另一個(gè)文件里。這個(gè)是用工具補(bǔ)足的 —— 在內(nèi)部的 code search 工具里我沒(méi)感覺(jué)不方便，在 github 沒(méi)有交叉引用的情況下看代碼就比較郁悶。
6：基于源代碼的開發(fā)(復(fù)用)，這是否違背了以前書上說(shuō)的實(shí)現(xiàn)隱藏(只暴露接口)?
沒(méi)，主要是因?yàn)?Google 統(tǒng)一代碼庫(kù)，Go 一開始?jí)焊鶝](méi)考慮二進(jìn)制庫(kù)發(fā)布的問(wèn)題。這跟軟件工程的隱藏實(shí)現(xiàn)是兩回事。依賴版本管理問(wèn)題同理，因?yàn)榻y(tǒng)一代碼庫(kù)+全主干提交，這個(gè)問(wèn)題在 Google 是不存在的…… 當(dāng)然問(wèn)題就是問(wèn)題，現(xiàn)在外部使用越來(lái)越多他們也在逐步補(bǔ)鍋了。
7：推崇error作為返回值是不對(duì)的。另外(panic+recover)對(duì)比下C++在C之上添加的異常處理(+RAII)的類型安全
推薦一篇微軟 Midori 項(xiàng)目 (Rethinking the software stack) 語(yǔ)言 leader 的 Joe Duffy – The Error Model (超長(zhǎng))。error 功能不夠好，但 C++ 和 Java 的 exception 機(jī)制在上規(guī)模后也有無(wú)法解決的工程和性能的問(wèn)題，Optional是好，但是語(yǔ)言就要變復(fù)雜，這里面有 tradeoff. 另外，「異常安全」是個(gè)看起來(lái)遵守規(guī)則寫就可以的簡(jiǎn)單事情，但實(shí)際上非常困難，比如事務(wù)的回滾，文中也有專門描述。
Shisoft Architect
因?yàn)?Go 語(yǔ)言的確是最搓的
就連 Go 語(yǔ)言最引以為傲的并發(fā)模型， 在某些語(yǔ)言里也就是一個(gè)庫(kù)就能解決的事情(clojure/core.async)。
語(yǔ)言就要做好語(yǔ)言該做的事情。語(yǔ)言特性太弱，runtime 不夠輕量，沒(méi)辦法做 system language 也是很正常的事情。也怪不了寫 C/C++ 和 Rust 的人看不上它。
我第一次看到一個(gè)現(xiàn)代通用，宣稱自己是 static typing 的編程語(yǔ)言下的第三方容器庫(kù)清一色拿 string 做 key，interface{} 做 value 是很傻眼的。給我一種喜歡寫 go 的都是之前習(xí)慣寫 php 和 javascript 的錯(cuò)覺(jué)。
Go 語(yǔ)言社區(qū)最大的問(wèn)題在于自身語(yǔ)言特性弱還給開發(fā)人員強(qiáng)加設(shè)計(jì)哲學(xué)，并宣稱這種做法是絕對(duì)正確的，你們只要無(wú)腦去用就可以了。靜態(tài)語(yǔ)言里我沒(méi)見過(guò)哪個(gè)語(yǔ)言的 map 和 list 是內(nèi)置的，并且還會(huì)幫你隱藏后面的實(shí)現(xiàn)算法。你如果需要一個(gè)特定的數(shù)據(jù)結(jié)構(gòu)容器，只能去忍受一次次的類型轉(zhuǎn)換。然后就又有一群人說(shuō) interface{} 用的多是寫的人太搓。humm…那你告訴我這個(gè)項(xiàng)目(mijia/gopark)里滿天飛的 interface{} 按照 Go 語(yǔ)言的設(shè)計(jì)哲學(xué)怎么消掉保證安全性，并且還不會(huì)有運(yùn)行時(shí)的性能損失。
其他的。話說(shuō)沒(méi)有 enum 嗎
所以 Go 語(yǔ)言也就是做做后端微服務(wù)之類勞動(dòng)密集型的應(yīng)用，還沒(méi)到可以和 java 現(xiàn)在的核心應(yīng)用競(jìng)爭(zhēng)的程度。
祭阿泣
幾個(gè)實(shí)際例子。
goroutine泄漏。goroutine雖然方便，但是粗心的開發(fā)者用爽了之后，會(huì)濫用goroutine，導(dǎo)致和內(nèi)存泄露類似的問(wèn)題(再搞一個(gè)垃圾goroutine回收機(jī)制?2333)。
官方包bug。之前用cgo封了個(gè)很簡(jiǎn)單的HttpClient給C調(diào)用，go1.5的gc在C程序中不完美，導(dǎo)致有時(shí)鏈接不會(huì)正常釋放，程序還會(huì)時(shí)不時(shí)hang在os.yield上。go1.6更新日志的第一句就是cgo完美支持gc，但是我試了一下這個(gè)問(wèn)題依然存在。還有什么不支持低版本ld(去go源碼中注釋掉一行代碼，然后重新編譯go就能“支持”了)。
官方包文檔。http包，transport，client這些類如果想要自己訂制一些功能，那么最好要搞清楚什么類開了什么goroutine，是不是端口需要手動(dòng)close，goroutine有沒(méi)有shutdown。這些文檔里沒(méi)有說(shuō)。
風(fēng)格。我真的很不喜歡寫一句話就寫n句if err!=nil{…｝，而且寫完之后還要想盡辦法去構(gòu)造單元測(cè)試來(lái)覆蓋這個(gè)分支。如果你覺(jué)得這個(gè)地方實(shí)在是不會(huì)出現(xiàn)err，那么就用_來(lái)吃掉這個(gè)err吧，然而以后每個(gè)看代碼的人都會(huì)看到這個(gè)_，然后想想為什么這里可以吃掉這個(gè)err，浪費(fèi)時(shí)間不喜歡。太過(guò)于嚴(yán)謹(jǐn)，需要更折中一些，個(gè)人覺(jué)得。
王岳楠
在一家省分行用go每天處理二千萬(wàn)條數(shù)據(jù)入數(shù)據(jù)倉(cāng)庫(kù)做數(shù)據(jù)分析，后臺(tái)用oci連oracle，前臺(tái)web只用了gorilla的mux庫(kù)，三個(gè)月來(lái)系統(tǒng)很穩(wěn)定，數(shù)據(jù)處理速度及報(bào)表交互速度很快。做過(guò)一個(gè)與核心對(duì)接的交易查詢系統(tǒng)，使用cgo與核心中間件對(duì)接，也很穩(wěn)定，數(shù)據(jù)庫(kù)mysql。還用go做了一個(gè)預(yù)算管理、一個(gè)服務(wù)器資源監(jiān)控系統(tǒng)和一個(gè)基于activity的workflow，做完的感覺(jué)就是我今后很長(zhǎng)時(shí)間還是會(huì)用go。以前做項(xiàng)目用過(guò)java，Python。Java的缺點(diǎn)是語(yǔ)法太啰嗦，虛擬機(jī)還得調(diào)優(yōu)。Python不能充分利用多核，部署也麻煩。golang優(yōu)點(diǎn)很明顯：語(yǔ)法像Python一樣靈活優(yōu)雅，后期運(yùn)維部署簡(jiǎn)單方便到讓我感動(dòng)(經(jīng)過(guò)python部署折磨后)，沒(méi)有泛型之類的語(yǔ)法我也基本把上述系統(tǒng)的業(yè)務(wù)邏輯都完成了，我不是個(gè)語(yǔ)言控，語(yǔ)言不必大而全，復(fù)雜了我也玩兒不轉(zhuǎn)，也不需要語(yǔ)法糖對(duì)別人炫耀(時(shí)間長(zhǎng)了我也看不懂)，對(duì)于我來(lái)說(shuō)就是把系統(tǒng)業(yè)務(wù)邏輯快速完成，開發(fā)部署越簡(jiǎn)單越好，系統(tǒng)一定要穩(wěn)定。golang滿足了我一切要求，真的有它就go了。
Irons Du
- 你能輕松知道哪些struct繼承(實(shí)現(xiàn))了哪些interface么?
- 你能輕松知道struct有哪些”成員函數(shù)”么?
- 手動(dòng)維護(hù)defer能比RAII輕松?更安全?怕不怕順序問(wèn)題?怕不怕寫露了?而且是函數(shù)作用域的。
- package只有一個(gè)層次，容易出現(xiàn)沖突。
- 訪問(wèn)控制只能限定在package之外。而且沒(méi)有static 函數(shù)等等。
- 基于源代碼的開發(fā)(復(fù)用)，這是否違背了以前書上說(shuō)的實(shí)現(xiàn)隱藏(只暴露接口)?
- 推崇error作為返回值是不對(duì)的。另外(panic+recover)對(duì)比下C++在C之上添加的異常處理(+RAII)的類型安全， defer 也沒(méi)有顯式的try catch直觀和精確控制。
- go是入門簡(jiǎn)單，學(xué)好難。難在多線程編程。Go能更容易寫出多線程程序。但對(duì)于一個(gè)需求明確的任務(wù)，我并不覺(jué)得通過(guò)仔細(xì)斟酌設(shè)計(jì)的C++多線程程序比Go差，反而更好，很多地方更容易控制。當(dāng)然這需要能力。但既然沒(méi)得能力，我相信同樣也寫不好Go的多線程程序。
ps，前[1-5]對(duì)于小項(xiàng)目問(wèn)題不大。
冒泡
只說(shuō)我個(gè)人對(duì)go的意見，由于用得不深可能有些說(shuō)得不對(duì)的地方
語(yǔ)言設(shè)計(jì)雖然要有創(chuàng)新，但語(yǔ)法這種東西搞太多創(chuàng)新反而會(huì)提高學(xué)習(xí)成本，比如在C++和go中切換一陣子，常常寫錯(cuò)string s和s string，當(dāng)然這是一個(gè)喜好問(wèn)題，花點(diǎn)力氣轉(zhuǎn)過(guò)來(lái)也不是困難
語(yǔ)法過(guò)于封閉和霸道，譬如map、range這種可以作為一個(gè)庫(kù)或方法的都實(shí)現(xiàn)為關(guān)鍵字，當(dāng)然，你說(shuō)這些常用，那沒(méi)啥問(wèn)題，但是我們能不能對(duì)于自定義的結(jié)構(gòu)，定義它自身的hash、eq來(lái)作為map的key，以及能不能定義自己的方法讓它可以被range呢，貌似沒(méi)找到辦法，不是很確定，如果有請(qǐng)告訴我呀
非入侵接口是有些優(yōu)勢(shì)，但會(huì)帶來(lái)比較大的效率損耗，雖然1.7出來(lái)后整體速度提了一截，但用不用interface的比對(duì)還是差距比較大的，另外這個(gè)設(shè)計(jì)本身的一些缺陷網(wǎng)上也有文章專門敘述，略了
沒(méi)泛型，比如，怎么定義一個(gè)可以和自身比較的類型的通用接口呢，即類似Java中>這種，如果用interface的話，貌似不能限定“只能和自身類型”，那只好運(yùn)行時(shí)動(dòng)態(tài)檢查?我因?yàn)檫@個(gè)問(wèn)題，看了sort庫(kù)的代碼，發(fā)現(xiàn)是從另一個(gè)角度繞過(guò)的，而且sort這么搞只能有效支持類似數(shù)組的結(jié)構(gòu)了，那我想寫個(gè)通用紅黑樹怎么設(shè)計(jì)接口呢，感覺(jué)比較困難
錯(cuò)誤處理很多人吐槽過(guò)了。其實(shí)我倒是沒(méi)那么強(qiáng)烈的意見，就是寫一些小腳本太啰嗦
cgo的性能，大部分語(yǔ)言的C擴(kuò)展很多時(shí)候是用來(lái)改寫核心模塊而提高效率，go卻不是，cgo的設(shè)計(jì)是有自己的苦衷，但能不能提供一種不走環(huán)境切換的選擇呢
曹東
每種語(yǔ)言都有適用場(chǎng)景，不太好同維度對(duì)比。
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ù)級(jí)的多(語(yǔ)法簡(jiǎn)單，但組合出的變化卻很多)4，開發(fā)效率高;5，編譯速度快、部署簡(jiǎn)單(以前靜態(tài)連接是一個(gè)賣點(diǎn)，后面版本開始支持動(dòng)態(tài)鏈接庫(kù)后走偏了);6，親爹支持。
其實(shí)go的社區(qū)還是很活躍的，國(guó)內(nèi)我所知的，很多公司開始將后臺(tái)、中間件遷移到go了，像百度的BFE7層接入系統(tǒng)、360的長(zhǎng)連接推送系統(tǒng)、美團(tuán)的廣告中間件、滴滴的認(rèn)證系統(tǒng)、七牛云平臺(tái)、鏈家、vmware、uber中國(guó)。名單會(huì)很長(zhǎng)很長(zhǎng)
姜太公
因?yàn)樵谧鯠ocker相關(guān)的事情，整個(gè)Docker生態(tài)基本上都是Go語(yǔ)言的，也不得不跟著使用Go。有幾個(gè)方面確實(shí)覺(jué)得很不爽
首先是錯(cuò)誤處理，由于沒(méi)有異常機(jī)制，只能寫大量的if err != nil。代碼里充斥著這種判斷。實(shí)際上很多時(shí)候我們并不需要出錯(cuò)之后進(jìn)行恢復(fù)，處理不了，只想把錯(cuò)誤往上拋。比如讀文件，用Python我可以這樣寫
- with open('file') as f:
- data = f.read()
文件不存在怎么辦?io錯(cuò)誤怎么辦?大多數(shù)時(shí)候我們沒(méi)辦法原地處理錯(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è)普通接口，通常只有一句簡(jiǎn)單錯(cuò)誤信息?？吹藉e(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ò)!我過(guò)去一看，依賴倒是沒(méi)問(wèn)題，項(xiàng)目本身的包找不到!Go要求代碼必須放在$GOPATH/src/下面，比如我的項(xiàng)目必須放在$GOPATH/src/http://github.com/xxxx/hello目錄下。
接口的實(shí)現(xiàn)方式，由于只要實(shí)現(xiàn)了所有的方法就算實(shí)現(xiàn)了接口，不用顯式聲明，所以光看代碼根本沒(méi)法找到到底實(shí)現(xiàn)了哪個(gè)/哪幾個(gè)接口。
黃川
個(gè)人覺(jué)得不是不受待見， 而是人自身的問(wèn)題：
第一：
現(xiàn)在招聘GO語(yǔ)言的工作很少，從大環(huán)境來(lái)看就是這樣，七牛算一個(gè)，然并卵，我不會(huì)因?yàn)橐环莨ぷ魅テ吲Ｋ诘牡貐^(qū)工作。
第二：
現(xiàn)在Java還是大行其道，大的技術(shù)公司主要編程需要還都是java或者C++，現(xiàn)在又有node這種怪胎(不要覺(jué)得我碰node，為什么node這么火，還不是入門門檻低，前端都會(huì)寫，但是軟件工程，系統(tǒng)架構(gòu)有幾個(gè)人懂，能寫出好代碼才怪，寫點(diǎn)小工具或者小型網(wǎng)站還是馬馬馬虎虎的，畢竟快，讓我們寫后端的童鞋寫一個(gè)網(wǎng)站沒(méi)幾個(gè)月寫不出來(lái)，界面不會(huì)寫啊，讓我哭一會(huì))，拉回來(lái)，一家公司想要轉(zhuǎn)新的語(yǔ)言，是多么大的風(fēng)險(xiǎn)，沒(méi)有沖勁的領(lǐng)導(dǎo)不敢干這事，所以Go始終還是小眾語(yǔ)言的存在，但是隨著Docker的普及，慢慢地大家也開始關(guān)注GO了，這是好事，還有微服務(wù)的推廣，跨語(yǔ)言的業(yè)務(wù)開發(fā)極大的幫助了Go的推廣。但是現(xiàn)階段還是安心寫Java吧。
第三：
我們知道業(yè)務(wù)代碼再往下下就倒系統(tǒng)了，GO對(duì)系統(tǒng)API的調(diào)用做得很好，直接syscall調(diào)用，可以聯(lián)編C代碼，多好啊，但是你會(huì)么，或者說(shuō)看這篇文章的人里面有幾個(gè)人自己研究過(guò)Linux或者Freebsd的底層接口，退一步，除了寫業(yè)務(wù)代碼之外沉下心研究過(guò)操作系統(tǒng)底層的有幾個(gè)?對(duì)于分布式原理的理解的有幾個(gè)?(吹牛逼的自己閉嘴，我說(shuō)的分布式原理，不是別的網(wǎng)站里面看幾篇文章就說(shuō)自己懂分布式)還有鎖，分布式鎖等概念，在并發(fā)編程里面都是需要注意的，有幾個(gè)人愿意花時(shí)間在這上面。
所以，不是Go不受待見，而是人自己固步自封，你必須承認(rèn)Go就是比java快，就是比PHP快，能做的事情更多，系統(tǒng)資源的使用更加淋漓盡致，雖然比不上C與C++，但是也算接近，而且編譯更快，自帶內(nèi)存管理，語(yǔ)法清晰。但是，你還是更喜歡把時(shí)間花在打游戲上，另外，喜歡就是喜歡，管別人待不待見Go呢。
當(dāng)前文章：為什么Go語(yǔ)言如此不受待見？
鏈接分享：http://www.dlmjj.cn/article/dppjpgg.html
