go語言有什麼缺點嗎

go語言的缺點：1、技術路線選擇導致的“性能劣勢”，go屬於GC類程式語言，在一些性能超級敏感的場合，選擇Go依然要慎重。 2.表達方法單一」、顯式的錯誤處理有點「過時」。3、最小版本選擇MVS，背離主流。4、Go核心團隊對語言演化的把控力十足，不是社區多數人贊同的就一定會被採納而加入Go語言，導致在社區上有劣勢，Go社區與Go核心團隊有「裂痕」。5、功能孱弱。

##本教程操作環境：windows7系統、GO 1.18版本、Dell G3電腦。

每種程式語言都有自己的優勢和劣勢，Go也不例外，下面我們就來列舉Go的那些「優點」和「劣勢」：

Go優勢

1、簡單易學

Go語言語法簡單，其中包含了類似C語言的語法。如果讀者已經掌握了兩到三門程式語言，那麼學習Go語言只需要幾天的時間。即使是一名剛入門的開發者，花幾個星期也能寫出性能較高的Go語言程式。

2、自由高效

Go語言的編譯速度明顯優於Java 和C ，還擁有接近C語言的運行效率以及接近PHP 的開發效率，可以說Go語言將運行效率和開發效率進行了完美的融合。

同時，Go語言也支援當前所有的程式設計範式，包括過程式設計、物件導向程式設計、面向介面程式設計、函數式程式設計。開發者們可依需求自由組合。

3、強大的標準函式庫

Go裡面的標準函式庫非常穩定且豐富多樣，包括網路、系統、加密、編碼、圖形等各個面向。尤其是網路和系統的函式庫非常實用，使得開發者在開發大型程式時，幾乎無須依賴第三方函式庫。

#4、部署方便

#不需要使用虛擬機，Go語言的程式碼可以直接輸出為二進位可執行檔。而且Go語言擁有自己的連結器，不依賴任何系統提供的編譯器和連結器。因此編譯出的二進位可執行檔幾乎可以運行在任何系統環境中。

5、原生支援並發

Go語言是一種非常有效率的語言，從語言層原生支援並發，使用起來非常簡單。Go語言的並發是基於Goroutine 的，Goroutine 類似於線程，但並非線程，是Go語言面向線程的輕量級方法。創建Goroutine 的成本很低，只需幾千個字節的額外內存。

通常一台普通的桌面主機運行上百個執行緒就會負載過大，而同樣的主機卻可以運行上千甚至上萬個Goroutine。Goroutine 之間可以透過channel 實現通訊。Goroutine 以及基於channel 的並發性方法可最大限度地使用CPU 資源。

6、穩定性強

Go語言擁有強大的編譯檢查、嚴格的編碼規格和很強的穩定性，此外Go語言還提供了軟體生命週期（如開發、測試、部署、維護等）的各個環節的工具，例如：go tool、go fmt、go test 等。

7、垃圾回收

在使用Go語言進行開發時，在記憶體方面開發者只需要關注記憶體的申請即可，並不需要關係記憶體的釋放，因為Go語言內建了runtime 來自動進行管理。雖然目前來說GC（Garbage Collection，垃圾回收機制）不算完美，但是足以應付開發時遇到的大多數情況，使開發者可以將更多精力集中在業務上，同時Go語言也允許開發者對此項工作進行最佳化。

Go的劣勢

1. 技術路線選擇導致的「效能劣勢」

眾所周知，Go是帶垃圾回收的程式語言，因此不管Go的STW(Stop The World)的時間有多麼短，GC的延遲有多麼的小，它依然屬於GC類程式語言，和Java、C#屬於一個陣營，同時天然與C、 C 、Rust這樣的手動管理記憶體、沒有運行時GC負擔的程式語言之間劃清了界線。雖然Go語言的初衷是成為系統級程式語言，雖然Go的運行時效能可以滿足99.99%的場合的需要，雖然百度的萬億流量[轉送引擎BFE]、時序資料庫[influxdb]、分散式關聯式資料庫[ TiDB]等性能敏感的項目都選擇了用Go實現，但不能否認的是在一些性能超級敏感的場合，選擇Go依然要慎重。

2 堅持自己的設計哲學所帶來的「表達劣勢」

1) 「單一」的表達方法

很多從其他語言轉到Go陣營的開發人員抱怨Go能玩的花樣太少，套路不多，Go之所以表現出“表達劣勢”，源於其設計哲學中的一個原則：“崇尚一個事情只有一個或少數幾種寫法”。這個原則不符合某些開發人員炫技的心理需求，於是Go就被詬病為是資質平平的程式設計師才會去用的語言。

[Go 1.18將加入泛型（型別參數）]，這算是對此類「劣勢」的一個「彌補」。不過對於我們這些對Go價值觀和設計哲學認同已久的Gopher而言，我們十分擔心大幅提高Go表達能力的[泛型]將成為奇技淫巧的「滋生地」。

2) 「過時」的明確的錯誤處理

Go語言從誕生那天起就沒有像C 、Java、Python等主流程式語言那樣提供基於異常（exception）的結構化try-catch-finally錯誤處理機制，Go的設計者認為[將異常耦合到程式控制結構中會導致程式碼混亂]。 Go提供了一種簡單的基於錯誤值比較的錯誤處理機制，這「強迫」每個Go開發人員都必須明確地去關注和處理每個錯誤，經過明確錯誤處理的程式碼會更為健壯，也會讓Go開發人員對這些程式碼更有信心。但這一設計哲學的堅持卻被許多來自其他語言的開發者嘲笑為“過時”，被稱為“半個世紀前的古老機制”。 (筆者註：十九世紀70年代C語言誕生時採用的錯誤處理機制)

Go開發團隊也曾“動搖過”，Go開發團隊在發布Go2計劃後曾發布過多版[Go錯誤處理的新機制草案]。 Go社區也針對此問題做過長時間的討論甚至是“爭吵”，知名Gopher Dave Cheney發聲、Rob Pike發聲，著名Go培訓師、《Go語言實戰》聯合作者之一的威廉·肯尼迪（William Kennedy）更是在Go團隊try 提案公告之後，發表了對​​Go社區的公開信反對try方案，最終堅持Go設計哲學的一派佔了上風，try提案被否決，沒有加入到[Go 1.13版本]中！

3. 背離主流的“小眾劣勢”

Go早期設計的包依賴管理機制的確存在不小的“瑕疵”，這源於Google內部大單一代碼倉庫與基於主幹的開發模型的影響。走出Google的Go語言聽到了不同面向的聲音，Go套件管理機制長期無法滿足社群的需求。於是先後出現了[vendor機制]、[dep]等對套件依賴管理的改進嘗試。

2018 年初，正當廣大gopher們認為dep將「順理成章」地升級為go官方工具鏈的一部分的時候，Go核心團隊的技術負責人，也是Go 核心團隊早期成員之一的Russ Cox在個人部落格上連續發表了 [七篇文章]，系統闡述了Go團隊解決「包依賴管理」的技術方案: [vgo]，即go module的前身。

vgo的主要想法包括：語意導入版本(Semantic Import Versioning)、最小版本選擇(Minimal Version Selection) ，這些都與目前主流程式語言的套件依賴管理的規則相悖，尤其是[最小版本選擇(MVS)]，算是另闢蹊徑，背離主流！

4. Go核心團隊的「民主集中製」導致的「社群劣勢」

和Rust團隊廣泛採納社群建議「猛加語言特性」不同，Go像是另一個極端：Go核心團隊對語言演化的把控力十足，不是社區多數人贊同的就一定會被採納而加入Go語言，我這裡將其戲稱為“民主集中製”吧，即真正的投票權其實在Go核心團隊的代表社群的少數人手中。

2018年初的dep與vgo之爭就是這「劣勢」的典型表現。社區費勁一年多努力精心打造的dep項目被Russ Cox等少數人集中花掉一些時間設計出的vgo給“擠出”了Go包依賴管理工具標準的位置，成為了Go module成功的“墊腳石” 。即便最終證明Go團隊使用go module的決策的結果是正確的，但這導致的Go社區與Go核心團隊的「裂痕」是確確實實存在的，以致於這兩年Go核心團隊極力改善與Go社區的關係，規範化和透明化Go proposal的提出、review和接納流程。

5. 全面出擊失敗後，期望的落空導致的「功能孱弱劣勢」

Go 1.5發布之後，由於實現了自舉和GC延遲的大幅下降，Go受關注程度逐漸升高，直至2017年初第二次拿到TIOBE年度最佳編程語言，讓Go語言有些“膨脹”，甚至狂熱的Go鼓吹者曾一度希望Go一統江湖：不僅牢牢把持住自己的雲原生市場，佔領Java的企業級市場，還要在終端機(android. ios)、前端(js)上擊敗現有對手。

有人可能覺得我上述的說法很可笑，但這些說法並非空穴來風。 Go語言在終端、前端方面還真的曾經發過力，了解Go歷史的都知道，Go團隊曾經有全職開發人員參與[gomobile專案](，該專案旨在建立在Android和iOS上的Go技術棧，實現用Go語言編寫終端應用的目的。

在前端方面，[gopherjs專案]可以將go程式碼編譯為js程式碼並運行於各大瀏覽器中。後來gopherjs的作者又幫助go專案原生支援webassembly，支援將go編譯為webassembly運行在瀏覽器中。

但上面的嘗試最終沒能“得償如願”，現狀是在終端、前端應用領域，使用Go編碼的人少之又少。於是Go又逐漸冷靜下來，回到自己擅長的主力戰場，回歸到了企業級應用、基礎設施、中間件、微服務、命令列應用等領域，並且在這些領域取得了越來越多開發者的青睞。

但曾經的全面出擊失敗給許多開發者留下了「Go功能孱弱」的口實，甚至有人說[親爹Google]也沒能讓親兄弟Android給Go走個後門。

【相關推薦：Go影片教學、程式設計教學】

以上是go語言有什麼缺點嗎的詳細內容。更多資訊請關注PHP中文網其他相關文章！