go語言的優勢和劣勢是什么

這篇“go語言的優勢和劣勢是什么”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“go語言的優勢和劣勢是什么”文章吧。

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

每種編程語言都有自己的優勢和劣勢，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語言的優勢和劣勢是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。