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語言有什麼缺點嗎的詳細內容，更多請關注TW511.COM其它相關文章！