建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
這是一個(gè)“Go不好”系列的額外文章。Go確實(shí)有一些不錯(cuò)的特性，也就是本文中“好的”部分，但是當(dāng)我們不使用API或者網(wǎng)絡(luò)服務(wù)器(這是為它設(shè)計(jì)的)而且將它用于業(yè)務(wù)領(lǐng)域邏輯的時(shí)候，總體而言我發(fā)現(xiàn)它用起來(lái)笨重且糟糕。但是即使在用于網(wǎng)絡(luò)編程的時(shí)候，在設(shè)計(jì)和實(shí)現(xiàn)方面它也有很多缺陷，這導(dǎo)致它在顯而易見(jiàn)的簡(jiǎn)單的表面之下是危險(xiǎn)的。
促使我寫(xiě)這篇文章的原因就是最近我又開(kāi)始用Go做一個(gè)副項(xiàng)目。在我之前的工作我廣泛地使用Go來(lái)寫(xiě)網(wǎng)絡(luò)代理(包括http和原生tcp)來(lái)做SaaS服務(wù)。網(wǎng)絡(luò)部分相當(dāng)不錯(cuò)(當(dāng)時(shí)我也是初次嘗試這個(gè)語(yǔ)言)，但是賬戶(hù)和賬單部分給我?guī)?lái)了痛苦。由于我的副項(xiàng)目做的是一個(gè)簡(jiǎn)單的API，我覺(jué)得Go應(yīng)該是可以快速完成這個(gè)工作的合適的工具，但是就像我們知道的，很多項(xiàng)目會(huì)擴(kuò)張并超過(guò)他們的初始范圍，因此我不得不寫(xiě)一些數(shù)據(jù)處理來(lái)做統(tǒng)計(jì)，然后使用Go就又變得痛苦了。因此下面是我對(duì)Go的問(wèn)題的看法。
一些背景：我喜歡靜態(tài)類(lèi)型語(yǔ)言。我的第一個(gè)重要項(xiàng)目是用Pascal編寫(xiě)的。在90年代初我開(kāi)始工作之時(shí)，我使用了Ada和C/C ++。后來(lái)我遷移到了Java，最后又使用了Scala(在期間還用過(guò)Go)，最近開(kāi)始學(xué)習(xí)Rust。我還寫(xiě)了大量的JavaScript代碼，因?yàn)橹钡阶罱荳eb瀏覽器中唯一可用的語(yǔ)言。對(duì)動(dòng)態(tài)類(lèi)型語(yǔ)言我感覺(jué)不牢靠，并嘗試將其應(yīng)用限制在簡(jiǎn)單腳本中。我對(duì)命令式、函數(shù)式和面向?qū)ο蟮姆椒ǜ械胶軡M(mǎn)意。
這是篇長(zhǎng)文，所以，這是讓你開(kāi)胃口的菜單目錄:
好的
- Go易于學(xué)習(xí)
- 易于并發(fā)編程的協(xié)程(goroutines )和通道(channels)
- 強(qiáng)大的標(biāo)準(zhǔn)庫(kù)
- 高性能GO
- 程序語(yǔ)言定義的源代碼格式
- Defer聲明，避免忘記清理
- 新類(lèi)型
不好之處
- GO忽略現(xiàn)代語(yǔ)言設(shè)計(jì)的進(jìn)步
- 接口是結(jié)構(gòu)類(lèi)型
- 沒(méi)有枚舉
- := / var的困境
- (讓人)恐慌的零值
- Go沒(méi)有異常
爛的
- 依賴(lài)關(guān)系管理的噩夢(mèng)
- 用語(yǔ)言硬編碼的可變性
- Slice陷阱
- 可變性和渠道:使競(jìng)態(tài)條件(race conditions)很容易
- 混亂的錯(cuò)誤管理
- Nil接口值
- Struct字段標(biāo)記:字符串中的運(yùn)行時(shí)DSL
- 沒(méi)有泛型…至少不是為了你
- Go在slice和map之外幾乎沒(méi)有什么數(shù)據(jù)結(jié)構(gòu)
- go generate: ok-ish，但是…
結(jié)語(yǔ)
優(yōu)點(diǎn)
Go容易學(xué)習(xí)
這是事實(shí)：如果你會(huì)任何一種編程語(yǔ)言，你可以通過(guò)“Go教程”在幾個(gè)小時(shí)之內(nèi)學(xué)會(huì)Go的大部分語(yǔ)法，在幾天之內(nèi)就可以寫(xiě)出你的第一個(gè)程序。閱讀和消化Effective Go，徘徊在標(biāo)準(zhǔn)庫(kù)中，運(yùn)用web工具包如Gorilla 或者Go kit，你就能成為一個(gè)相當(dāng)不錯(cuò)的Go開(kāi)發(fā)者。
這是因?yàn)镚o的首要目標(biāo)就是簡(jiǎn)單。當(dāng)我開(kāi)始學(xué)習(xí)Go的時(shí)候，它讓我回憶起了我初次接觸Java：一個(gè)豐富卻不臃腫的簡(jiǎn)單語(yǔ)言。與現(xiàn)在的Java繁重的環(huán)境對(duì)比，學(xué)習(xí)Go是一個(gè)新鮮的體驗(yàn)。由于Go的簡(jiǎn)單，Go程序是非常易讀的，即使錯(cuò)誤處理方面有不少麻煩(這下面更多)。
但是這可能并不是真的簡(jiǎn)單。引用 Rob Pike的話，簡(jiǎn)單即復(fù)雜，我們?cè)谙旅婵梢钥吹皆诤竺嬗泻芏嗟南葳宓戎覀儯?jiǎn)潔和極簡(jiǎn)主義阻止了我們編寫(xiě)DRY原則的代碼。
使用goroutines 和 channels簡(jiǎn)單的并發(fā)編程
Goroutines可能是Go的最好的特性。與操作系統(tǒng)線程不同，他們是輕量級(jí)的計(jì)算線程。
當(dāng)一個(gè)Go程序執(zhí)行阻塞I/O操作一類(lèi)的工作時(shí)，實(shí)際上Go實(shí)時(shí)掛起了這個(gè)goroutine，而且在一個(gè)event表明一些結(jié)果已經(jīng)可以訪問(wèn)之后，會(huì)重新運(yùn)行。在此期間，其他goroutines已經(jīng)在為執(zhí)行調(diào)度。因此我們?cè)谑褂靡粋€(gè)同步編程模型做異步編程的時(shí)候有可擴(kuò)展性的優(yōu)點(diǎn)。
Goroutines也是輕量級(jí)的：他們的棧按需增加或減少，也就是說(shuō)有數(shù)百個(gè)甚至數(shù)千個(gè)goroutines都不是問(wèn)題。
在一個(gè)應(yīng)用中我曾經(jīng)有一個(gè)goroutine泄露：在結(jié)束之前這些goroutines等待一個(gè)channel去關(guān)閉，但那個(gè)channel不會(huì)關(guān)閉(一個(gè)常見(jiàn)的死鎖問(wèn)題)。這個(gè)進(jìn)程平白占了90%的CPU，查看expvars顯示60萬(wàn)個(gè)空的goroutine!我猜CPU都被goroutine調(diào)度占用了。
當(dāng)然，一個(gè)像Akka的actor系統(tǒng)可以不費(fèi)力氣就處理數(shù)百萬(wàn)actors，一部分是因?yàn)閍ctors沒(méi)有棧，但是他們?cè)趯?xiě)復(fù)雜并發(fā)request/response應(yīng)用(如 http APIs)時(shí)不如goroutine簡(jiǎn)單的多。
Channels是goroutines之間交互的通道：他們提供了一個(gè)方便的編程模型可以在goroutines之間發(fā)送和接收數(shù)據(jù)，而不用依賴(lài)脆弱的底層同步原語(yǔ)。Channels擁有他們自己的一套使用模式。
由于錯(cuò)誤的channels數(shù)量(他們默認(rèn)無(wú)緩沖)會(huì)導(dǎo)致死鎖，Channels必須要慎重考慮。我們?cè)谙旅嬉矔?huì)提到因?yàn)镚o缺少不變性，使用channels并不能阻止?fàn)帗屬Y源。
強(qiáng)大的標(biāo)準(zhǔn)庫(kù)
Go標(biāo)準(zhǔn)庫(kù)真的很強(qiáng)大，特別是對(duì)網(wǎng)絡(luò)協(xié)議相關(guān)的所有東西或者API開(kāi)發(fā)：http 客戶(hù)端和服務(wù)器，加密，壓縮格式，壓縮，發(fā)送郵件等等。甚至還有html解析器和相當(dāng)強(qiáng)大的模板引擎，通過(guò)自動(dòng)escaping可以用來(lái)產(chǎn)生文字&html來(lái)避免XSS(在Hugo 模板的示例中使用)。
大多數(shù)情況下APIs通常是簡(jiǎn)單易懂的。盡管有時(shí)候他們看起來(lái)過(guò)于簡(jiǎn)單：這當(dāng)中，一部分是由于goroutine編程模式告訴我們只需要關(guān)心“看似同步”的操作。另一部分是因?yàn)樯贁?shù)通用的多功能函數(shù)能替代大量單一功能的函數(shù)，就像最近一段時(shí)間，我發(fā)現(xiàn)的那些用于時(shí)間計(jì)算的函數(shù)一樣。
GO是高性能的
Go編譯成一個(gè)本地可執(zhí)行文件。許多Go的用戶(hù)來(lái)自于Python，Ruby或者Node.js。對(duì)他們來(lái)說(shuō)，這是個(gè)令人興奮的體驗(yàn)，因?yàn)樗麄儼l(fā)現(xiàn)服務(wù)器可以處理的并發(fā)請(qǐng)求數(shù)量大幅的增加。對(duì)于沒(méi)有并發(fā)的語(yǔ)言(Node.js)或者全局解釋器鎖(GIL)來(lái)說(shuō)，這實(shí)際上是再正常不過(guò)的事情。結(jié)合語(yǔ)言的簡(jiǎn)單性，這說(shuō)明了Go語(yǔ)言令人興奮的一面。
然而相比Java，在原始性能基準(zhǔn)測(cè)試中，情況并不是那么清晰。在內(nèi)存使用和垃圾收集方面Go力壓Java。
Go的垃圾收集的設(shè)計(jì)目的是優(yōu)先考慮延遲和避免stop-the-world停頓，這在服務(wù)器中尤其重要。這可能會(huì)帶來(lái)更高的CPU成本，但是在水平可伸縮的架構(gòu)(horizontally scalable architecture)中通過(guò)添加更多的機(jī)器這是易于解決的。記住，Go是Google設(shè)計(jì)的，他們不缺資源。
相比于Java，Go的GC在要做的工作方面也更少的：slice的結(jié)構(gòu)是一個(gè)連續(xù)的結(jié)構(gòu)數(shù)組，而不是像Java這樣的指針數(shù)組。相似地，Go的maps出于同樣的目的使用像桶的小數(shù)組。這意味著在GC上工作量更少，并且還更有利于CPU的緩存位置。
Go也可以力壓Java的命令行實(shí)用程序：一個(gè)本地可執(zhí)行的，Go程序?qū)ava的首先必須加載和編譯字節(jié)碼來(lái)說(shuō)沒(méi)有啟動(dòng)成本。
語(yǔ)言所定義的源代碼格式
在我職業(yè)生涯中一些最激烈的爭(zhēng)論發(fā)生在團(tuán)隊(duì)代碼格式的定義上。Go通過(guò)為Go代碼定義規(guī)范格式解決了這個(gè)問(wèn)題。gofmt工具會(huì)重新格式化你的代碼，并且沒(méi)有選項(xiàng)。
不管喜不喜歡，gofmt都定義了Go代碼應(yīng)該如何格式化，因此該問(wèn)題得到一次性解決!
標(biāo)準(zhǔn)化的測(cè)試框架
Go在其標(biāo)準(zhǔn)庫(kù)中提供了一個(gè)很好的測(cè)試框架。它支持并行測(cè)試、基準(zhǔn)測(cè)試，并且包含很多用于輕松測(cè)試網(wǎng)絡(luò)客戶(hù)端和服務(wù)器的使用程序。
Go程序非常適合運(yùn)維
與Python、Ruby或Node.js相比，僅安裝單個(gè)可執(zhí)行文件對(duì)于運(yùn)維工程師來(lái)說(shuō)是一個(gè)夢(mèng)想。隨著越來(lái)越多的Docker投入使用，這個(gè)問(wèn)題出現(xiàn)的越來(lái)越少，但獨(dú)立的可執(zhí)行文件也意味著更小的Docker鏡像。
Go還具有一些內(nèi)置的可觀察性功能，使用expvar包發(fā)布內(nèi)部狀態(tài)和指標(biāo)，并且可以輕松添加新內(nèi)容。但要小心，因?yàn)樗鼈冊(cè)谀J(rèn)的http請(qǐng)求處理程序中自動(dòng)暴露，變得不受保護(hù)。Java中JMX有類(lèi)似的功能，但它更復(fù)雜。
Defer語(yǔ)句，用于避免遺忘清理
defer語(yǔ)句的作用類(lèi)似于Java中的finally：在當(dāng)前函數(shù)結(jié)束時(shí)執(zhí)行一些清理代碼，并不管此函數(shù)是如何退出的。有關(guān)defer的有趣的事情是它沒(méi)有鏈接到一段代碼上，并可以隨時(shí)出現(xiàn)。這允許清理代碼盡可能靠近創(chuàng)建那些需要清理資源的代碼：
- file, err := os.Open(fileName)
- if err != nil {
- return
- }
- defer file.Close()
- // use file, we don't have to think about closing it anymore
當(dāng)然，Java的“try-with-resource”不是那么冗長(zhǎng)，同時(shí)Rust在資源的所有者被刪除時(shí)會(huì)自動(dòng)聲明資源，但由于Go要求你對(duì)資源清理明確了解，因此讓它靠近資源分配的地方將其關(guān)閉是很不錯(cuò)的。
自定義類(lèi)型
我喜歡自定義類(lèi)型，而且我惱怒/害怕一些情況，就好像當(dāng)我們來(lái)回傳一個(gè)字符串型或者long型的持久化對(duì)象標(biāo)識(shí)符的時(shí)候。我們經(jīng)常對(duì)參數(shù)名為id的類(lèi)型編碼，但是這就是一些產(chǎn)生小bug的原因，即當(dāng)一個(gè)函數(shù)有多個(gè)標(biāo)識(shí)符作為參數(shù)的時(shí)候，一些調(diào)用就會(huì)弄混參數(shù)順序。
Go的自定義類(lèi)型支持first-class，例如那些分配給一個(gè)已有類(lèi)型的獨(dú)立的標(biāo)識(shí)符的類(lèi)型，可以與原來(lái)的標(biāo)識(shí)符區(qū)分開(kāi)來(lái)。與封裝相反，自定義類(lèi)型沒(méi)有運(yùn)行時(shí)開(kāi)銷(xiāo)。這使得編譯器能捕獲這種錯(cuò)誤：
- type UserId string // <-- new type
- type ProductId string
- func AddProduct(userId string, productId string) {}
- func main() {
- userId := UserId("some-user-id")
- productId := ProductId("some-product-id")
- // Right order: all fine
- AddProduct(userId, productId)
- // Wrong order: would compile with raw strings
- AddProduct(productId, userId)
- // Compilation errors:
- // cannot use productId (type ProductId) as type UserId in argument to AddProduct
- // cannot use userId (type UserId) as type ProductId in argument to AddProduct
- }
不幸的是，對(duì)那些要求自定義類(lèi)型與原始類(lèi)型做轉(zhuǎn)換的人來(lái)說(shuō)，由于不支持泛型，自定義類(lèi)型在寫(xiě)復(fù)用代碼的時(shí)候用起來(lái)比較累贅。
不好之處
GO忽略現(xiàn)代語(yǔ)言設(shè)計(jì)的進(jìn)步
在大道至簡(jiǎn)(Less is exponentially more)的演講上，Rob Pike解釋說(shuō)Go是要取代C和C++的，它的前身是Newsqueak，這是他在80年代寫(xiě)的一種語(yǔ)言。Go也有很多關(guān)于Plan9的參考，這是一個(gè)分布式操作系統(tǒng)，80年代在貝爾實(shí)驗(yàn)室開(kāi)發(fā)的。
甚至有一個(gè)Go組件直接從Plan9獲得靈感。為什么不使用LLVM來(lái)提供范圍廣泛的目標(biāo)體系結(jié)構(gòu)呢?我可能也在這里漏掉了什么，但為什么需要呢?如果你需要編寫(xiě)程序集以充分利用CPU，那么你不是應(yīng)該直接使用目標(biāo)CPU匯編語(yǔ)言嗎?
Go的設(shè)計(jì)者很值得尊敬，但是他們就像在一個(gè)平行宇宙(或者他們的Plan9實(shí)驗(yàn)室)設(shè)計(jì)的Go，在那里大多數(shù)編譯器和編程語(yǔ)言的設(shè)計(jì)都不是在90年代和2000年代。或者是那些能寫(xiě)編譯器的系統(tǒng)編程人員設(shè)計(jì)了Go。
函數(shù)式編程?沒(méi)有提到它。泛型?你不需要它們，看看它們?cè)贑++里產(chǎn)生的混亂吧!哪怕slice，map和channels都是泛型類(lèi)型，就像接下來(lái)我們會(huì)看到的。
Go的目標(biāo)就是代替C和C++，但是很明顯它的設(shè)計(jì)者沒(méi)有多看看其他語(yǔ)言。他們避開(kāi)了他們的目標(biāo)，Google的C和C++開(kāi)發(fā)者不采用它。我猜主要原因就是垃圾回收。低級(jí)C開(kāi)發(fā)者十分抗拒管理內(nèi)存，因?yàn)樗麄儾涣私夤芾硎裁?，在什么時(shí)候管理。他們喜歡這種控制，即使會(huì)帶來(lái)額外的復(fù)雜，而且打開(kāi)內(nèi)存泄露和buffer溢出的大門(mén)。有趣的是，Rust在不使用GC的情況下使用另一種方法做自動(dòng)內(nèi)存管理。
相反的，在操作工具方面Go吸引了那些像使用Python和Ruby等腳本語(yǔ)言的人。他們?cè)贕o中發(fā)現(xiàn)一個(gè)方法，有很好的性能，而且減少了內(nèi)存/cpu/硬盤(pán)的占用空間。而且也是更static的類(lèi)型，這對(duì)他們來(lái)說(shuō)是新穎的。對(duì)GO來(lái)說(shuō)Docker是殺手級(jí)應(yīng)用，這使得它在開(kāi)發(fā)界開(kāi)始被廣泛使用。Kubernetes的提出加強(qiáng)了這個(gè)趨勢(shì)。
Interfaces是結(jié)構(gòu)化類(lèi)型(structural types)
Go的interfaces就像Java的interfaces或者Scala和Rust的traits：他們定義行為，之后才會(huì)被一個(gè)type(我在這不把他們叫做“class”)實(shí)現(xiàn)。
不像Java的interfaces和Scala和Rust的traits，一個(gè)type不需要明確定義它實(shí)現(xiàn)了一個(gè)interface：它必須要實(shí)現(xiàn)所有定義在interfaces中的函數(shù)。因此Go的interfaces的確是structural types。
我們也許認(rèn)為Go允許在其他的packages中實(shí)現(xiàn)interface，而不僅僅是在type所在的packages中申請(qǐng)，就像Scala、Kotlin的類(lèi)擴(kuò)展和Rust的trait一樣。但事實(shí)并非如此：與type相關(guān)的所有方法都必須在這個(gè)type的package中定義。
Go并不是唯一使用structural typing的語(yǔ)言，但我發(fā)現(xiàn)它存在幾個(gè)缺點(diǎn)：
- 尋找有哪些type實(shí)現(xiàn)了interface是困難的，因?yàn)樗蕾?lài)于函數(shù)定義匹配。在Java或Scala中，我經(jīng)常通過(guò)搜索實(shí)現(xiàn)了interface的類(lèi)來(lái)尋找相關(guān)的實(shí)現(xiàn)。
- 當(dāng)給interface添加一個(gè)方法時(shí)，你將會(huì)發(fā)現(xiàn)只有當(dāng)那些types被用作interface type的值時(shí)，type才會(huì)被更新。很長(zhǎng)一段時(shí)間內(nèi)你會(huì)忽視這種問(wèn)題。Go建議盡少使用有只有幾個(gè)方法的interfaces，以此來(lái)防止該問(wèn)題的發(fā)生。
- 因?yàn)閠ype中有一個(gè)方法與interface相同，這個(gè)type可能會(huì)無(wú)意中實(shí)現(xiàn)了一個(gè)interface。但是偶然的情況下，它所實(shí)現(xiàn)的功能可能與預(yù)想的interface協(xié)議不同。
更新：interface的一些丑陋的地方，請(qǐng)?jiān)斂春竺娴摹癷nterface空值”章節(jié)。
沒(méi)有枚舉類(lèi)型
Go中沒(méi)有枚舉值，在我看來(lái)這是一個(gè)錯(cuò)失的機(jī)會(huì)。
iota可以快速生成自增的數(shù)值，但它看起來(lái)更像是一種修改而非特性。而實(shí)際上，由于在一系列iota所生成的常量中插入一行會(huì)改變其后面的值是一個(gè)危險(xiǎn)的操作。由于所生成的值是在整個(gè)代碼中使用的，因此這可能會(huì)觸發(fā)意外。
這也意味著在Go中沒(méi)有辦法讓編譯器檢查switch語(yǔ)句是否詳盡，并且無(wú)法描述給定類(lèi)型所支持的值。
:= / var 的尷尬
Go提供了兩種方法聲明和分配給變量一個(gè)值：var x = “foo” 和 x := “foo”，為什么這樣?
主要區(qū)別是：var允許聲明而不初始化(那你就必須聲明類(lèi)型)，就像var x string，然而 :=要求分配一個(gè)值，而且這種方法可以同樣用于已有變量和新變量。我猜發(fā)明:=就是用來(lái)讓我們?cè)诓东@錯(cuò)誤的時(shí)候不那么痛苦的：
使用var:
- var x, err1 = SomeFunction()
- if (err1 != nil) {
- return nil
- }
- var y, err2 = SomeOtherFunction()
- if (err2 != nil) {
- return nil
- }
使用:= ：
- x, err := SomeFunction()
- if (err != nil) {
- return nil
- }
- y, err := SomeOtherFunction()
- if (err != nil) {
- return nil
- }
:=語(yǔ)法也容易不小心對(duì)一個(gè)變量重新賦值。我曾經(jīng)不止一次遇到這個(gè)問(wèn)題，就像:=(聲明和分配)與=(分配)太像了，就像下面這樣：
- foo := "bar"
- if someCondition {
- foo := "baz"
- doSomething(foo)
- }
- // foo == "bar" even if "someCondition" is true
零值恐慌
Go里沒(méi)有構(gòu)造函數(shù)。因此，它奉行“零值”應(yīng)該可以隨時(shí)使用。這是一個(gè)有趣的方法，但在我看來(lái)，它所帶來(lái)的簡(jiǎn)化化主要是針對(duì)語(yǔ)言實(shí)現(xiàn)者的。
在實(shí)踐中，如果沒(méi)有正確的初始化，許多類(lèi)型都不能做有用的事情。讓我們來(lái)看一下在Effective Go中作為示例的io.Fileobject：
- type File struct {
- *file // os specific
- }
- func (f *File) Name() string {
- return f.name
- }
- func (f *File) Read(b []byte) (n int, err error) {
- if err := f.checkValid("read"); err != nil {
- return 0, err
- }
- n, e := f.read(b)
- return n, f.wrapErr("read", e)
- }
- func (f *File) checkValid(op string) error {
- if f == nil {
- return ErrInvalid
- }
- return nil
- }
我們?cè)谶@里能看到什么呢?
- 在零值文件上調(diào)用Name()將會(huì)出現(xiàn)問(wèn)題，因?yàn)樗膄ile字段為nil。
- Read函數(shù)和File幾乎所有其他的方法都一樣，首先檢查文件是否已初始化。
所以基本上零值文件不僅沒(méi)用，而且會(huì)導(dǎo)致問(wèn)題。你必須使用以下構(gòu)造函數(shù)中的一個(gè)：如“Open”或“Create”。檢查是否正確的初始化是每次函數(shù)調(diào)用都必須承受的開(kāi)銷(xiāo)。
標(biāo)準(zhǔn)庫(kù)中有無(wú)數(shù)類(lèi)似這樣的類(lèi)型，有些甚至不試圖使用它們的零值做一些有用的事情。在零值的html.Template上調(diào)用任何方法：它們都引起問(wèn)題。
同時(shí)map的零值有個(gè)嚴(yán)重的缺陷：它可以查詢(xún)，但在map中存儲(chǔ)任何數(shù)據(jù)都有導(dǎo)致panic異常：
- var m1 = map[string]string{} // empty map
- var m0 map[string]string // zero map (nil)
- println(len(m1)) // outputs '0'
- println(len(m0)) // outputs '0'
- println(m1["foo"]) // outputs ''
- println(m0["foo"]) // outputs ''
- m1["foo"] = "bar" // ok
- m0["foo"] = "bar" // panics!
當(dāng)結(jié)構(gòu)具有map字段時(shí)，就要當(dāng)心了，因?yàn)樵谙蚱涮砑訔l目之前必須對(duì)其進(jìn)行初始化。
因此，身為一名開(kāi)發(fā)人員，你必須經(jīng)常檢查你要使用的結(jié)構(gòu)體是否需要調(diào)用構(gòu)造函數(shù)或者零值是否有用。為了一些語(yǔ)言上的簡(jiǎn)化，這將給代碼編寫(xiě)者帶來(lái)很大的負(fù)擔(dān)。
Go中沒(méi)有異常
博客文章“為何Go處理異常是正確的”中詳細(xì)解釋了為什么異常是很糟糕的，以及為什么Go中的方法需要返回錯(cuò)誤是更好的作法。我同意這一點(diǎn)，并且在使用異步編程或像Java流這樣的函數(shù)式風(fēng)格時(shí)，異常是很難處理的(讓我們暫且將之拋之腦后，因?yàn)榍罢咴贕o中是不需要的，這要?dú)w功于goroutine;而后者根本不可能)。該博文中提到panic是“對(duì)你的程序總是致命的，游戲結(jié)束”，這是對(duì)的。
現(xiàn)在，“Defer, panic和recove”在這之前，解釋了如何從panic中恢復(fù)過(guò)來(lái)(實(shí)際上通過(guò)捕獲它們)，并說(shuō)：“對(duì)于一個(gè)真實(shí)世界的panic和恢復(fù)示例，請(qǐng)參閱Go標(biāo)準(zhǔn)庫(kù)中的json包。
事實(shí)上，json解碼器有一個(gè)會(huì)觸發(fā)panic的通用的錯(cuò)誤處理函數(shù)，在最頂層的unmarshall函數(shù)中可恢復(fù)該panic，該函數(shù)將檢查panic類(lèi)型，并在其是“l(fā)ocal panic”時(shí)將其作為錯(cuò)誤返回，或重新觸發(fā)panic錯(cuò)誤(在此丟失了原來(lái)的panic堆棧跟蹤信息)。
對(duì)于任一Java開(kāi)發(fā)人員來(lái)說(shuō)，這看起來(lái)像try / catch (DecodingException ex)。所以Go確實(shí)有異常，僅在內(nèi)部使用但建議你不要使用。
有趣的是：幾個(gè)星期前，一個(gè)非googler修復(fù)了json解碼器，其中使用常規(guī)錯(cuò)誤冒泡。
丑陋的
依賴(lài)關(guān)系管理的噩夢(mèng)
一位知名的Google Go開(kāi)發(fā)者Jaana Dogan(又名JBD)，最近在推特上發(fā)泄他的不滿(mǎn)：
如果依賴(lài)關(guān)系管理不能在一年解決，我會(huì)考慮棄用Go并且永遠(yuǎn)不再回來(lái)。依賴(lài)性管理問(wèn)題通常會(huì)改變我從語(yǔ)言中獲得的所有樂(lè)趣。
- 133
- 有44人在談?wù)撨@件事
讓我們把它簡(jiǎn)單化：Go中沒(méi)有依賴(lài)項(xiàng)管理，所有當(dāng)前的解決方案都只是一些技巧和變通方法。
這可以追溯回谷歌的起源階段，眾所周知，谷歌使用了一個(gè)巨大的單塊存儲(chǔ)庫(kù)，用于所有源代碼。不需要模塊版本控制，不需要第三方模塊存儲(chǔ)庫(kù)，你在你當(dāng)前分支上build任何(你想要的)東西。不幸的是，這在開(kāi)放的互聯(lián)網(wǎng)上行不通。
為 Go 添加依賴(lài)就表示將依賴(lài)項(xiàng)的源代碼庫(kù)拷貝到 GOPATH 中。但是是什么版本呢?是克隆時(shí)的 master 分支，不管它是哪個(gè)版本。如果不同項(xiàng)目需要不同版本的依賴(lài)項(xiàng)怎么辦呢?沒(méi)辦法。版本的概念甚至不存在。
同時(shí)，自己的項(xiàng)目也要放在 GOPATH，否則編譯器就找不到它。你是否想讓項(xiàng)目整潔的組織在各自獨(dú)立的目錄中呢?那就必須想為每個(gè)項(xiàng)目設(shè)置 GOPATH 或恰當(dāng)?shù)慕⒎线B接。
社區(qū)中設(shè)計(jì)出來(lái)的方法帶來(lái)了大量工具。包管理工具引入了提供方和 lock 文件，它們包含的 Git ShA1 可以支持重復(fù)構(gòu)建。
vendor 目錄最終在 Go 1.6 中得到了官方支持。但對(duì)于克隆的供應(yīng)內(nèi)容，仍然沒(méi)有合適的版本管理。也不能通過(guò)語(yǔ)義化版本解決混淆導(dǎo)入和依賴(lài)傳遞的問(wèn)題。
不過(guò)情況正在好轉(zhuǎn)：dep，最近出現(xiàn)了這個(gè)官方依賴(lài)管理工具用于支持供應(yīng)內(nèi)容。它支持版本(git tags)，同時(shí)具有支持語(yǔ)義化版本約定的版本解析器。這個(gè)工具尚未達(dá)到穩(wěn)定版本，但它在做正確的事情。而且，它仍然需要你把項(xiàng)目放在 GOPATH 目錄下。
但dep可能不會(huì)存在太久，因?yàn)関go，也來(lái)自Google，想在語(yǔ)言本身中引入版本信息并且近期一直在發(fā)起一些此類(lèi)的浪潮。
所以Go中的依賴(lài)管理是噩夢(mèng)般的存在。完成配置是很痛苦的，而你在開(kāi)發(fā)過(guò)程中從沒(méi)有考慮過(guò)它，直到你添加一個(gè)新的導(dǎo)入或者簡(jiǎn)單地想把你的一個(gè)團(tuán)隊(duì)成員的一個(gè)分支拉到你的GOPATH中時(shí)…
現(xiàn)在讓我們回到代碼上吧。
可變性在語(yǔ)言中是硬編碼的
在Go中沒(méi)有辦法定義不可變的結(jié)構(gòu)體：struct字段是可變的，而const關(guān)鍵詞不適用于它們。Go可以很容易地通過(guò)簡(jiǎn)單的賦值來(lái)完成整個(gè)結(jié)構(gòu)的復(fù)制，因此我們可能會(huì)認(rèn)為按值傳參是以復(fù)制為代價(jià)以實(shí)現(xiàn)不變性的前提。
然而，毫不奇怪，這不會(huì)復(fù)制由指針引用的值。由于內(nèi)置集合(map，slice和array)是引用并且是可變的，所以復(fù)制包含其中之一的結(jié)構(gòu)體只會(huì)將復(fù)制指向同一后臺(tái)內(nèi)存的指針。
下面的示例說(shuō)明這一點(diǎn)：
- type S struct {
- A string
- B []string
- }
- func main() {
- x := S{"x-A", []string{"x-B"}}
- y := x // copy the struct
- y.A = "y-A"
- y.B[0] = "y-B"
- fmt.Println(x, y)
- // Outputs "{x-A [y-B]} {y-A [y-B]}" -- x was modified!
- }
所以你必須對(duì)此非常小心，并且如果你是通過(guò)傳值來(lái)傳遞參數(shù)的話，則不要假定它是不可變的。
有一些deepcopy庫(kù)試圖用(慢)反射來(lái)解決這個(gè)問(wèn)題，但由于專(zhuān)有字段不能被反射訪問(wèn)，所以它們存在不足之處。因此可避免競(jìng)態(tài)條件的預(yù)防式復(fù)制將會(huì)是很困難的，需要大量的樣板代碼。Go甚至沒(méi)有可以標(biāo)準(zhǔn)化的Clone接口。
Slice陷阱
Slices帶來(lái)了很多陷阱：就像在“Go slices: usage and internals”中解釋的一樣，由于一些性能原因，re-slicing一個(gè)slice不會(huì)復(fù)制底層數(shù)組。它 的目的是好的，但這意味著一個(gè)slice中的子slice僅僅是繼承了原始slice的mutations的視圖。因此如果你想將子slice與原始的slice區(qū)分，不要忘了copy()這個(gè)slice。
因?yàn)閍ppend函數(shù)，忘記調(diào)用copy()會(huì)很危險(xiǎn)：如果它沒(méi)有足夠的容量存儲(chǔ)新值，在一個(gè)slice中append一個(gè)值會(huì)改變底層數(shù)組的大小。這就意味著append的結(jié)果可能會(huì)也可能不會(huì)指向依賴(lài)初始化容量的原始的數(shù)組。這會(huì)導(dǎo)致很難找到不確定的bugs。
在下面的代碼我們看到一個(gè)函數(shù)將值append到一個(gè)子slice改變了使用容量初始化的原始slice產(chǎn)生的結(jié)果。
- func doStuff(value []string) {
- fmt.Printf("value=%v\n", value)
- value2 := value[:]
- value2 = append(value2, "b")
- fmt.Printf("value=%v, value2=%v\n", value, value2)
- value2[0] = "z"
- fmt.Printf("value=%v, value2=%v\n", value, value2)
- }
- func main() {
- slice1 := []string{"a"} // length 1, capacity 1
- doStuff(slice1)
- // Output:
- // value=[a] -- ok
- // value=[a], value2=[a b] -- ok: value unchanged, value2 updated
- // value=[a], value2=[z b] -- ok: value unchanged, value2 updated
- slice10 := make([]string, 1, 10) // length 1, capacity 10
- slice10[0] = "a"
- doStuff(slice10)
- // Output:
- // value=[a] -- ok
- // value=[a], value2=[a b] -- ok: value unchanged, value2 updated
- // value=[z], value2=[z b] -- WTF?!? value changed???
- }
Mutability 和 channels:更容易產(chǎn)生競(jìng)爭(zhēng)條件
Go的并發(fā)是使用channels在CSP上建立的，這會(huì)使相應(yīng)的goroutines比同步共享數(shù)據(jù)更加簡(jiǎn)單和安全。這里的mantra是“不要通過(guò)共享內(nèi)存來(lái)通信;相反，通過(guò)通信來(lái)共享內(nèi)存”。然而這只是一廂情愿，實(shí)際上并不能安全的完成這個(gè)目標(biāo)。
就像我們之前看到的，在Go中沒(méi)有方法使用不可變數(shù)據(jù)結(jié)構(gòu)。這意味著我們使用channel發(fā)送一個(gè)指針，就玩完了：我們?cè)诓l(fā)進(jìn)程共享了可變數(shù)據(jù)。當(dāng)然structures(不是指針)的一個(gè)channel復(fù)制了在channel上發(fā)送的值，但是就像我們之前看到的，這不是深度復(fù)制引用，包括slices和maps，他們本質(zhì)上都是可變的。一個(gè)interface type的結(jié)構(gòu)字段也是一樣：他們是指針，interface定義的任何mutation方法都是通向競(jìng)爭(zhēng)條件的大門(mén)。
因此雖然channels明顯讓并發(fā)編程更簡(jiǎn)單，他們不阻止在共享數(shù)據(jù)里的競(jìng)爭(zhēng)條件。而且slices和maps的本質(zhì)可變性讓這種情況更容易發(fā)生。
來(lái)說(shuō)一下競(jìng)爭(zhēng)條件，Go包含了一個(gè)競(jìng)爭(zhēng)條件的檢測(cè)模式，這些代碼工具是用來(lái)尋找未同步的共享訪問(wèn)。它只能在他們出問(wèn)題的時(shí)候檢測(cè)競(jìng)爭(zhēng)問(wèn)題，因此大多都是在集成或負(fù)載測(cè)試中使用，借此期望產(chǎn)生會(huì)引發(fā)競(jìng)爭(zhēng)條件的問(wèn)題。在生產(chǎn)中，實(shí)際上這并不可行，因?yàn)樗母哌\(yùn)行時(shí)代價(jià)，除了臨時(shí)debug sessions。
雜亂的錯(cuò)誤管理
在Go中你需要快速學(xué)習(xí)的是錯(cuò)誤處理模式，因?yàn)榉磸?fù)出現(xiàn)：
- someData, err := SomeFunction()
- if err != nil {
- return err;
- }
由于Go聲稱(chēng)不支持異常(雖然它支持異常)，但每個(gè)可能以錯(cuò)誤結(jié)尾的函數(shù)都必須有error作為其最終處理結(jié)果。 這尤其適用于執(zhí)行一些I / O功能，因此這種冗長(zhǎng)的模式在網(wǎng)絡(luò)應(yīng)用程序中非常普遍，這是Go的主要領(lǐng)域。
你的眼睛會(huì)很快為這種模式開(kāi)發(fā)一個(gè)可視化過(guò)濾器，并將其識(shí)別為“是的，錯(cuò)誤處理”，但仍然有很多其他干擾，有時(shí)很難在錯(cuò)誤處理過(guò)程中找到實(shí)際的代碼。
雖然有一些陷阱，因?yàn)殄e(cuò)誤結(jié)果實(shí)際上可能只是一個(gè)表面上的情況，例如從普遍存在的io.Reader讀取時(shí)：
- len, err := reader.Read(bytes)
- if err != nil {
- if err == io.EOF {
- // All good, end of file
- } else {
- return err
- }
- }
在“有價(jià)值錯(cuò)誤”中，Rob Pike提出了一些減少冗長(zhǎng)錯(cuò)誤處理的策略。 我發(fā)現(xiàn)他們實(shí)際上是危險(xiǎn)的救急：
- type errWriter struct {
- w io.Writer
- err error
- }
- func (ew *errWriter) write(buf []byte) {
- if ew.err != nil {
- return // Write nothing if we already errored-out
- }
- _, ew.err = ew.w.Write(buf)
- }
- func doIt(fd io.Writer) {
- ew := &errWriter{w: fd}
- ew.write(p0[a:b])
- ew.write(p1[c:d])
- ew.write(p2[e:f])
- // and so on
- if ew.err != nil {
- return ew.err
- }
- }
基本上，從以上認(rèn)識(shí)到，檢查錯(cuò)誤提供一種一直令人痛苦的模式，直到結(jié)束時(shí)才忽略寫(xiě)入序列中的錯(cuò)誤。 因此，即使我們知道它不應(yīng)該執(zhí)行，任何執(zhí)行的操作都會(huì)在執(zhí)行完錯(cuò)誤后執(zhí)行。 如果這些比分片更昂貴呢? 我們只是浪費(fèi)資源，因?yàn)镚o的錯(cuò)誤處理是一件痛苦的事情。
Rust有一個(gè)類(lèi)似的問(wèn)題：沒(méi)有異常處理(與Go相反，沒(méi)有)，函數(shù)可能失敗后返回Result ，并且需要對(duì)結(jié)果進(jìn)行一些模式匹配。 所以Rust1.0帶有try! 宏指令認(rèn)識(shí)到這種模式的普遍性，并做成一流的語(yǔ)言功能。 因此，您在保持正確的錯(cuò)誤處理的同時(shí)保持上述代碼的簡(jiǎn)潔。
不幸的是，將Rust的方法轉(zhuǎn)換為Go是不可能的，因?yàn)镚o沒(méi)有泛型或宏。
無(wú)接口值
在一次更新后，出現(xiàn)redditor jmickeyd顯示nil和接口的奇怪行為，這十分丑陋。 我把它擴(kuò)展了一點(diǎn)：
- type Explodes interface {
- Bang()
- Boom()
- }
- // Type Bomb implements Explodes
- type Bomb struct {}
- func (*Bomb) Bang() {}
- func (Bomb) Boom() {}
- func main() {
- var bomb *Bomb = nil
- var explodes Explodes = bomb
- println(bomb, explodes) // '0x0 (0x10a7060,0x0)'
- if explodes != nil {
- explodes.Bang() // works fine
- explodes.Boom() // panic: value method main.Bomb.Boom called using nil *Bomb pointer
- }
- }
上面的代碼驗(yàn)證了explode不是nil，但是code在Boom中冒出來(lái)，但不在Bang中。 這是為什么? 解釋一下在println行中：bomb指針是0x0，實(shí)際上是nil，但explodes是非空值(0x10a7060,0x0)。
該pair的第一個(gè)元素是指向由Explodes類(lèi)型所實(shí)現(xiàn)的Bomb接口的方法的調(diào)度表的指針，第二個(gè)元素是實(shí)際Explodes對(duì)象的地址，該地址為nil。
對(duì)Bang的調(diào)用成功了，因?yàn)樗鼞?yīng)用在指向Bomb的指針上：不需要解引用該指針來(lái)調(diào)用該方法。Boom方法操作一個(gè)值，因此一個(gè)調(diào)用導(dǎo)致指針被解引用，這會(huì)導(dǎo)致panic。
請(qǐng)注意，如果我們寫(xiě)了var explode Explodes = nil，那么!= nil將不會(huì)成功。
那么我們應(yīng)該如何以安全的方式編寫(xiě)測(cè)試? 我們必須對(duì)接口值和非零值都進(jìn)行nil-check，檢查接口對(duì)象指向的值…使用反射!
- if explodes != nil && !reflect.ValueOf(explodes).IsNil() {
- explodes.Bang() // works fine
- explodes.Boom() // works fine
- }
錯(cuò)誤或功能? Tour of Go有一個(gè)專(zhuān)門(mén)的頁(yè)面來(lái)解釋這種行為，并明確指出：“請(qǐng)注意，一個(gè)具有nil值的接口值本身不是零”。
不過(guò)，這很丑陋，可能會(huì)導(dǎo)致很微小的錯(cuò)誤。 它在語(yǔ)言設(shè)計(jì)中看起來(lái)像是一個(gè)很大的缺陷，使其實(shí)現(xiàn)更容易。
結(jié)構(gòu)字段標(biāo)簽：運(yùn)行時(shí)字符串中的DSL
如果您在Go中使用過(guò)JSON，您肯定遇到過(guò)類(lèi)似的情況：
- type User struct {
- Id string `json:"id"`
- Email string `json:"email"`
- Name string `json:"name,omitempty"`
- }
這些語(yǔ)言規(guī)范所說(shuō)的結(jié)構(gòu)標(biāo)簽是一個(gè)字符串“通過(guò)反射接口可見(jiàn)并參與結(jié)構(gòu)的類(lèi)型標(biāo)識(shí)，但是被忽略”。 所以基本上，寫(xiě)上任何你想要的字符串，并在運(yùn)行時(shí)使用反射來(lái)解析它。 如果語(yǔ)法不對(duì)，會(huì)在運(yùn)行時(shí)會(huì)出現(xiàn)宕機(jī)。
這個(gè)字符串實(shí)際上是字段元數(shù)據(jù)，在許多語(yǔ)言中已經(jīng)存在了數(shù)十年的“注釋”或“屬性”。 通過(guò)語(yǔ)言支持，它們的語(yǔ)法在編譯時(shí)被正式定義和檢查，同時(shí)仍然是可擴(kuò)展的。
為什么Go決定使用原始字符串，并且任何庫(kù)都可以決定是否使用它想要的任何DSL，在運(yùn)行時(shí)解析?
當(dāng)您使用多個(gè)庫(kù)時(shí)，情況可能會(huì)變得尷尬：下面是從協(xié)議緩沖區(qū)的Go文檔中取出的一個(gè)例子：
- type Test struct {
- Label *string `protobuf:"bytes,1,req,name=label" json:"label,omitempty"`
- Type *int32 `protobuf:"varint,2,opt,name=type,def=77" json:"type,omitempty"`
- Reps []int64 `protobuf:"varint,3,rep,name=reps" json:"reps,omitempty"`
- Optionalgroup *Test_OptionalGroup `protobuf:"group,4,opt,name=OptionalGroup" json:"optionalgroup,omitempty"`
- }
邊注：為什么在使用JSON的時(shí)候有很多常見(jiàn)的標(biāo)簽。因?yàn)樵贕o中，public的字段必須使用大駱駝命名法，或者至少以大寫(xiě)字母開(kāi)始。然而在JSON中，常見(jiàn)的字段命名習(xí)慣用小駱駝命名法或者蛇形命名法。因此需要很多冗長(zhǎng)的標(biāo)簽。
JSON編碼器和解碼器標(biāo)準(zhǔn)不允許提供命名策略來(lái)轉(zhuǎn)自動(dòng)轉(zhuǎn)化，就像Java中的Jackson文檔。這就解釋了為什么在Docker APIs的所有的字段都是大駝峰命名法：避免他的開(kāi)發(fā)人員為他們的大型API寫(xiě)這些麻煩的標(biāo)簽。
沒(méi)有泛型……至少不適合你
很難想象一個(gè)沒(méi)有泛型的現(xiàn)代靜態(tài)類(lèi)型語(yǔ)言，但這就是你用Go得到的東西：它沒(méi)有泛型……或者更確切地說(shuō)幾乎沒(méi)有泛型，正如我們將看到的那樣，這使得它比沒(méi)有泛型更糟糕。
內(nèi)置切片，地圖，數(shù)組和通道是通用的。 聲明一個(gè)map [string] MyStruct清楚地顯示了使用具有兩個(gè)參數(shù)的泛型類(lèi)型。 這很好，因?yàn)樗试S類(lèi)型安全編程捕捉各種錯(cuò)誤。
然而，沒(méi)有用戶(hù)可定義的泛型數(shù)據(jù)結(jié)構(gòu)。這意味著你無(wú)法以類(lèi)型安全的方式定義可用于任何一個(gè)type的可復(fù)用abstractions。你必須使用untyped的interface{}并且需要將值轉(zhuǎn)成合適的type。任何錯(cuò)誤都只會(huì)在運(yùn)行時(shí)捕獲，并且產(chǎn)生了panic。作為一個(gè)Java開(kāi)發(fā)者，這就像回到了之前2004年Java5時(shí)代。
在 “Less is exponentially more“中，Rob Pike驚人的將泛型和繼承放進(jìn)了同一個(gè)“typed programming”包中，說(shuō)他贊成組合替換繼承。不喜歡繼承是可以的(事實(shí)上，我寫(xiě)Scala的時(shí)候很少使用繼承)但是泛型解決了另一個(gè)問(wèn)題：在保持類(lèi)型安全的同時(shí)有可復(fù)用性。
正如接下來(lái)我們將看到的，把內(nèi)置的泛型與用戶(hù)定義的非泛型分隔開(kāi)，對(duì)開(kāi)發(fā)者的“舒適度”和編譯時(shí)的類(lèi)型安全產(chǎn)生了影響：它影響了整個(gè)Go的生態(tài)系統(tǒng)。
Go除了分片和映射之外幾乎沒(méi)有數(shù)據(jù)結(jié)構(gòu)
Go生態(tài)系統(tǒng)沒(méi)有很多數(shù)據(jù)結(jié)構(gòu)，它們可以從內(nèi)置切片和貼圖中提供額外的功能或不同的功能。 Go的最新版本添加了其中幾個(gè)的容器包。 他們都有同樣的說(shuō)明：他們處理interface{}值，這意味著你失去了所有類(lèi)型的安全機(jī)制。
我們來(lái)看看sync.Map的一個(gè)例子，它是一個(gè)具有較低線程爭(zhēng)用的并發(fā)映射，而不是使用互斥鎖來(lái)保護(hù)常規(guī)映射：
- type MetricValue struct {
- Value float64
- Time time.Time
- }
- func main() {
- metric := MetricValue{
- Value: 1.0,
- Time: time.Now(),
- }
- // Store a value
- m0 := map[string]MetricValue{}
- m0["foo"] = metric
- m1 := sync.Map{}
- m1.Store("foo", metric) // not type-checked
- // Load a value and print its square
- foo0 := m0["foo"].Value // rely on zero-value hack if not present
- fmt.Printf("Foo square = %f\n", math.Pow(foo0, 2))
- foo1 := 0.0
- if x, ok := m1.Load("foo"); ok { // have to make sure it's present (not bad, actually)
- foo1 = x.(MetricValue).Value // cast interface{} value
- }
- fmt.Printf("Foo square = %f\n", math.Pow(foo1, 2))
- // Sum all elements
- sum0 := 0.0
- for _, v := range m0 { // built-in range iteration on map
- sum0 += v.Value
- }
- fmt.Printf("Sum = %f\n", sum0)
- sum1 := 0.0
- m1.Range(func(key, value interface{}) bool { // no 'range' for you! Provide a function
- sum1 += value.(MetricValue).Value // with untyped interface{} parameters
- return true // continue iteration
- })
- fmt.Printf("Sum = %f\n", sum1)
- }
這是個(gè)很好的例子來(lái)解釋為什么Go的生態(tài)系統(tǒng)中沒(méi)有太多的數(shù)據(jù)結(jié)構(gòu)：與內(nèi)置的slice和map相比它們用起來(lái)很痛苦。出于一個(gè)簡(jiǎn)單的原因：Go的數(shù)據(jù)結(jié)構(gòu)中只有兩大類(lèi)。
- aristocracy，內(nèi)置的slice，map，array和channel：類(lèi)型安全，通用且調(diào)用range方便，
- Go代碼寫(xiě)的其他的類(lèi)型：不提供類(lèi)型安全，因?yàn)樾枰獜?qiáng)制轉(zhuǎn)換所以用起來(lái)笨拙。
所以庫(kù)定義的數(shù)據(jù)結(jié)構(gòu)必須為我們開(kāi)發(fā)者提供很多實(shí)在的好處，讓我們?cè)敢飧冻鍪ヮ?lèi)型安全和額外冗長(zhǎng)代碼的代價(jià)。
當(dāng)我們想要編寫(xiě)可重用的算法時(shí)，內(nèi)置結(jié)構(gòu)和Go代碼之間的雙重性更加微妙。 這是標(biāo)準(zhǔn)庫(kù)的排序包對(duì)排序片段的一個(gè)例子：
- import "sort"
- type Person struct {
- Name string
- Age int
- }
- // ByAge implements sort.Interface for []Person based on the Age field.
- type ByAge []Person
- func (a ByAge) Len() int { return len(a) }
- func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
- func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }
- func SortPeople(people []Person) {
- sort.Sort(ByAge(people))
- }
等等…這是真的嗎? 我們必須定義一個(gè)新的ByAge類(lèi)型，它必須實(shí)現(xiàn)3種方法來(lái)橋接泛型(“可重用”)排序算法和類(lèi)型化片段。
對(duì)于我們開(kāi)發(fā)者來(lái)說(shuō)，唯一需要關(guān)注的一件事，就是用于比較兩個(gè)對(duì)象的Less函數(shù)，并且它是域依賴(lài)的。其他一切都是干擾，因?yàn)镚o沒(méi)有泛型所以出現(xiàn)了模板。我們不得不一次次地重復(fù)使用它，包括我們想去排序的每個(gè)type和comparator。
更新：Michael Stapelberg指導(dǎo)我去看被我遺漏的sort.Slice。它在底層使用了反射，而且要求排序的時(shí)候，在slice上comparator函數(shù)得形成一個(gè)閉包。雖然這看起來(lái)會(huì)好些，但它依舊丑陋。
對(duì)于Go不需要泛型的所有解釋都是在告訴我們這就是“Go方式”，Go允許有可復(fù)用的算法來(lái)避免向下轉(zhuǎn)型成interface{}…
好了，現(xiàn)在來(lái)緩解一下痛苦，如果Go能用宏來(lái)生成這些無(wú)意義的模板將會(huì)變得美好一些，對(duì)嗎?
go generate：還行，但是…
Go 1.4引入了 go generate command命令來(lái)觸發(fā)源代碼中注釋的代碼生成。 那么，這里的“注釋”實(shí)際上意味著一個(gè)神奇的// go：generate，用嚴(yán)格的規(guī)則生成注釋?zhuān)骸白⑨尡仨殢男械拈_(kāi)始處開(kāi)始并且在//和go:generate之間沒(méi)有空格”。 弄錯(cuò)了，增加一個(gè)空格，沒(méi)有空格工具會(huì)警告你。
這實(shí)際上涵蓋了兩種用例：
- 從其他來(lái)源生成Go代碼：ProtoBuf / Thrift / Swagger模式，語(yǔ)言文法等
- 生成補(bǔ)充現(xiàn)有代碼的Go代碼，例如作為示例給出的stringer，它為一系列類(lèi)型常量生成一個(gè)String()方法。
第一個(gè)用例是可以正常使用的，附加的是你不必使用Makefiles，生成指令可以接近生成的代碼的用法。
對(duì)于第二種用例，許多語(yǔ)言(如Scala和Rust)都有宏(在設(shè)計(jì)文檔中提到)可在編譯期間訪問(wèn)源代碼的AST。 Stringer實(shí)際上導(dǎo)入了Go編譯器的解析器來(lái)遍歷AST。 Java沒(méi)有宏，但注釋處理器扮演著相同的角色。
許多語(yǔ)言也不支持宏，因此除了這種脆弱的注釋驅(qū)動(dòng)語(yǔ)法之外，沒(méi)有任何根本性的錯(cuò)誤，除了這種脆弱的注釋驅(qū)動(dòng)的語(yǔ)法之外，它看起來(lái)像是一種快速破解，它不知道怎么做了這個(gè)工作，而不是被認(rèn)真考慮為連貫的語(yǔ)言設(shè)計(jì)。
哦，你知道Go編譯器實(shí)際上有許多注釋/雜注和條件編譯使用這種脆弱的注釋語(yǔ)法?
結(jié)論
正如你可能猜到的那樣，我與Go有著或愛(ài)或恨的關(guān)系。 Go有點(diǎn)像一個(gè)朋友，你喜歡和他在一起，因?yàn)樗苡腥ぃ苓m合一起喝啤酒閑談，但是當(dāng)你想要進(jìn)行更深入的對(duì)話時(shí)，你會(huì)覺(jué)得無(wú)聊或痛苦，而且你不想與他去一起度假
我喜歡Go編寫(xiě)高效的API及網(wǎng)絡(luò)工具的簡(jiǎn)單性，這歸功于Goroutine，我討厭它在我必須實(shí)現(xiàn)業(yè)務(wù)邏輯時(shí)限制我的表現(xiàn)力，并且我討厭它的所有怪異和陷阱等著你踩進(jìn)去。
直到最近，Go還沒(méi)有真正的替代品，它正在開(kāi)發(fā)高效的本地可執(zhí)行文件，而不會(huì)產(chǎn)生C或C ++的痛苦。Rust正在迅速發(fā)展，我越玩越多，我發(fā)現(xiàn)它越來(lái)越有趣和設(shè)計(jì)得非常好。我有一種感覺(jué)，Rust是需要一段時(shí)間才能相處的朋友之一，但是你最終會(huì)想要與他們建立長(zhǎng)期合作關(guān)系。
回到更技術(shù)的層面，你會(huì)發(fā)現(xiàn)文章中說(shuō)的Rust和Go并不是一個(gè)層面的，由于Rust沒(méi)有GC等原因，Rust是一個(gè)系統(tǒng)語(yǔ)言。我認(rèn)為這越來(lái)越不符合實(shí)際。Rust在大型web框架和優(yōu)秀的ORM中的地位正在逐漸升高。它也給你一種親切感：“如果它是編譯器，錯(cuò)誤會(huì)出現(xiàn)在我寫(xiě)的邏輯上，而不是我忘記注意的語(yǔ)言特性上”。
我們也從容器/服務(wù)網(wǎng)格領(lǐng)域上看到一些有趣的活動(dòng)，包括使用Rust寫(xiě)的高效Sozu代理，或者Buoyant(Likerd的開(kāi)發(fā)者)開(kāi)發(fā)的他們的新Kubernetes服務(wù)網(wǎng)格Conduit來(lái)作為Go和Rust的結(jié)合，其中Go作為控制層(我猜由于現(xiàn)有的 Kubernetes 庫(kù))，Rust作為數(shù)據(jù)層因?yàn)樗母咝Ш徒选?/p>
Swift也是可以替代C和C++語(yǔ)言的家族的一部分。盡管它的生態(tài)仍然太以Apple為中心，但是現(xiàn)在它在Linux是可以用的，而且出現(xiàn)了服務(wù)端API和Netty框架。
現(xiàn)在當(dāng)然沒(méi)有萬(wàn)能和完全通用的技術(shù)。但是了解你使用的這些工具的缺點(diǎn)是很重要的。我希望這個(gè)博客已經(jīng)讓你了解到了一些關(guān)于Go的你曾經(jīng)沒(méi)意識(shí)到的問(wèn)題，這樣你就可以避免陷阱而不會(huì)被陷進(jìn)去!
當(dāng)前題目：Go語(yǔ)言的美好和丑陋解析
標(biāo)題路徑：http://www.fisionsoft.com.cn/article/cosiijj.html
