Go語言的9大優點和3大缺點,　GO語言最初的定位就是互聯網時代的C語言,　我爲何放棄Go語言

時間 2019-11-11

標籤語言優點缺點最初定位就是互聯網時代 c語言爲何放棄欄目系統網絡简体版

原文原文鏈接

Go語言的9大優點和3大缺點

轉用一門新語言一般是一項大決策，尤爲是當你的團隊成員中只有一個使用過它時。今年 Stream 團隊的主要編程語言從 Python 轉向了 Go。本文解釋了其背後的九大緣由以及如何作好這一轉換。html

Go的優點java

緣由 1：性能node

Go 極其地快。其性能與 Java 或 C++類似。在咱們的使用中，Go 通常比 Python 要快 30 倍。如下是 Go 與 Java 之間的基準比較：python

緣由 2：語言性能很重要c++

對不少應用來講，編程語言只是簡單充當了其與數據集之間的膠水。語言自己的性能經常無關輕重。git

可是 Stream 是一個 API 提供商，服務於世界 500 強以及超過 2 億的終端用戶。數年來咱們已經優化了 Cassandra、PostgreSQL、Redis 等等，然而最終抵達了所使用語言的極限。程序員

Python 很是棒，可是其在序列化/去序列化、排序和聚合中表現欠佳。咱們常常會遇到這樣的問題：Cassandra 用時 1ms 檢索了數據，Python 卻須要 10ms 將其轉化成對象。github

緣由 3：開發者效率&不要過於創新golang

看一下絕佳的入門教程《開始學習 Go 語言》(http://howistart.org/posts/go/1/)中的一小段代碼：算法

package main
type openWeatherMap struct{}func (w openWeatherMap) temperature(city string) (float64, error) {
resp, err := http.Get("http://api.openweathermap.org/data/2.5/weather?APPID=YOUR_API_KEY&q=" + city)
if err != nil {
return 0, err
}
defer resp.Body.Close()
var d struct {
Main struct {
Kelvin float64 `json:"temp"`
} `json:"main"`
}
if err := json.NewDecoder(resp.Body).Decode(&d); err != nil {
return 0, err
}
log.Printf("openWeatherMap: %s: %.2f", city, d.Main.Kelvin)
return d.Main.Kelvin, nil}

若是你是一個新手，看到這段代碼你並不會感到吃驚。它展現了多種賦值、數據結構、指針、格式化以及內置的 HTTP 庫。

當我第一次編程時，我很喜歡使用 Python 的高階功能。Python 容許你創造性地使用正在編寫的代碼，好比，你能夠：

在代碼初始化時，使用 MetaClasses 自行註冊類別
置換真假
添加函數到內置函數列表中
經過奇妙的方法重載運算符

毋庸置疑這些代碼頗有趣，但也使得在讀取其餘人的工做時，代碼變得難以理解。

Go 強迫你堅持打牢基礎，這也就爲讀取任意代碼帶來了便利，並能很快搞明白當下發生的事情。

注意：固然如何容易仍是要取決於你的使用案例。若是你要建立一個基本的 CRUD API，我仍是建議你使用 Django + DRF，或者 Rails。

緣由 4：併發性&通道

Go 做爲一門語言致力於使事情簡單化。它並未引入不少新概念，而是聚焦於打造一門簡單的語言，它使用起來異常快速而且簡單。其惟一的創新之處是 goroutines 和通道。Goroutines 是 Go 面向線程的輕量級方法，而通道是 goroutines 之間通訊的優先方式。

建立 Goroutines 的成本很低，只需幾千個字節的額外內存，正因爲此，才使得同時運行數百個甚至數千個 goroutines 成爲可能。你能夠藉助通道實現 goroutines 之間的通訊。Go 運行時間能夠表示全部的複雜性。Goroutines 以及基於通道的併發性方法使其很是容易使用全部可用的 CPU 內核，並處理併發的 IO——全部不帶有複雜的開發。相較於 Python/Java，在一個 goroutine 上運行一個函數須要最小的樣板代碼。你只需使用關鍵詞「go」添加函數調用：

package main
import (
"fmt"
"time")func say(s string) {
for i := 0; i < 5; i++ {
time.Sleep(100 * time.Millisecond)
fmt.Println(s)
}}func main() {
go say("world")
say("hello")}

Go 的併發性方法很是容易上手，相較於 Node 也頗有趣;在 Node 中，開發者必須密切關注異步代碼的處理。

併發性的另外一個優質特性是競賽檢測器，這使其很容易弄清楚異步代碼中是否存在競態條件。下面是一些上手 Go 和通道的很好的資源：

https://gobyexample.com/channels
https://tour.golang.org/concurrency/2
http://guzalexander.com/2013/12/06/golang-channels-tutorial.html
https://www.golang-book.com/books/intro/10
https://www.goinggo.net/2014/02/the-nature-of-channels-in-go.html

緣由 5：快速的編譯時間

當前咱們使用 Go 編寫的最大微服務的編譯時間只需 6 秒。相較於 Java 和 C++呆滯的編譯速度，Go 的快速編譯時間是一個主要的效率優點。我熱愛擊劍，可是當我依然記得代碼應該作什麼之時，事情已經完成就更好了。

Go 以前的代碼編譯

緣由 6：打造團隊的能力

首先，最明顯的一點是：Go 的開發者遠沒有 C++和 Java 等舊語言多。據知，有 38% 的開發者瞭解 Java，19.3% 的開發者瞭解 C++，只有 4.6% 的開發者知道 Go。GitHub 數據代表了類似的趨勢：相較於 Erlang、Scala 和 Elixir，Go 更爲流行，可是相較於 Java 和 C++ 就不是了。

幸運的是 Go 很是簡單，且易於學習。它只提供了基本功能而沒有多餘。Go 引入的新概念是「defer」聲明，以及內置的帶有 goroutines 和通道的併發性管理。正是因爲 Go 的簡單性，任何的 Python、Elixir、C++、Scala 或者 Java 開發者皆可在一月內組建成一個高效的 Go 團隊。

緣由 7：強大的生態系統

對咱們這麼大小的團隊(大約 20 人)而言，生態系統很重要。若是你須要重作每塊功能，那就沒法爲客戶創造收益了。Go 有着強大的工具支持，面向 Redis、RabbitMQ、PostgreSQL、Template parsing、Task scheduling、Expression parsing 和 RocksDB 的穩定的庫。

Go 的生態系統相比於 Rust、Elixir 這樣的語言有很大的優點。固然，它又略遜於 Java、Python 或 Node 這樣的語言，但它很穩定，並且你會發如今不少基礎需求上，已經有高質量的文件包可用了。

緣由 8：GOFMT，強制代碼格式

Gofmt 是一種強大的命令行功能，內建在 Go 的編譯器中來規定代碼的格式。從功能上看，它相似於 Python 的 autopep8。格式一致很重要，但實際的格式標準並不老是很是重要。Gofmt 用一種官方的形式規格代碼，避免了沒必要要的討論。

緣由 9：gRPC 和 Protocol Buffers

Go 語言對 protocol buffers 和 gRPC 有一流的支持。這兩個工具能一塊兒友好地工做以構建須要經過 RPC 進行通訊的微服務器(microservices)。咱們只須要寫一個清單(manifest)就能定義 RPC 調用發生的狀況和參數，而後從該清單將自動生成服務器和客戶端代碼。這樣產生代碼不只快速，同時網絡佔用也很是少。

從相同的清單，咱們能夠從不一樣的語言生成客戶端代碼，例如 C++、Java、Python 和 Ruby。所以內部通訊的 RESET 端點不會產生分歧，咱們每次也就須要編寫幾乎相同的客戶端和服務器代碼。

使用 Go 語言的缺點

缺點 1：缺乏框架

Go 語言沒有一個主要的框架，如 Ruby 的 Rails 框架、Python 的 Django 框架或 PHP 的 Laravel。這是 Go 語言社區激烈討論的問題，由於許多人認爲咱們不該該從使用框架開始。在不少案例狀況中確實如此，但若是隻是但願構建一個簡單的 CRUD API，那麼使用 Django/DJRF、Rails Laravel 或 Phoenix 將簡單地多。

缺點 2：錯誤處理

Go 語言經過函數和預期的調用代碼簡單地返回錯誤(或返回調用堆棧)而幫助開發者處理編譯報錯。雖然這種方法是有效的，但很容易丟失錯誤發生的範圍，所以咱們也很難向用戶提供有意義的錯誤信息。錯誤包(errors package)能夠容許咱們添加返回錯誤的上下文和堆棧追蹤而解決該問題。

另外一個問題是咱們可能會忘記處理報錯。諸如 errcheck 和 megacheck 等靜態分析工具能夠避免出現這些失誤。雖然這些解決方案十分有效，但可能並非那麼正確的方法。

缺點 3：軟件包管理

Go 語言的軟件包管理絕對不是完美的。默認狀況下，它沒有辦法制定特定版本的依賴庫，也沒法建立可複寫的 builds。相比之下 Python、Node 和 Ruby 都有更好的軟件包管理系統。然而經過正確的工具，Go 語言的軟件包管理也能夠表現得不錯。

咱們能夠使用 Dep 來管理依賴項，它也能指定特定的軟件包版本。除此以外，咱們還能夠使用一個名爲 VirtualGo 的開源工具，它能輕鬆地管理 Go 語言編寫的多個項目。

這個「火」字看你怎麼理解了。
Go在國內更火只是感受上的。好比推文，以及談論的相關話題較多而已(但能有nodejs多麼？)，自己中國人口數量就多，按這個衡量的辦法去看的話，swift在國內也比在國外火；
實際上Go在國外更火（這裏的火是實際的使用狀況），對比一下國內和國外使用Go的程度、數量，Go相關的技術大會舉辦的頻率和數量就一目瞭然了。

Go在國內真正上被全棧使用的就七牛一家，但國外除了docker，coreOS還有不少初創企業。
國內比較有影響力的就一個beego框架，你看看國外的有多少。

去github上搜一下active的Go的project數量，看看Go在國外是否是沒人用？我反正在github的trending裏面幾乎天天都能看到Go的project。hacker news上面有關Go的「xxx writen in Go」的炒做文也不要太多。
這個 dariubs/GoBooks · GitHub 是有人整理的Go相關的書籍，看看是否是國外的書籍比國內的少？8月份K&R中的K也要推出屬於Go的聖經了。 另外老有人喜歡說：Google喜歡關閉產品，這玩意兒早晚死掉。惋惜golang是開源項目，關不掉的，CloudFlare那個crypto的patch(Gerrit Code Review)之後可能會進Go的標準庫，Godep已經成爲事實上的包管理標準，這些都是社區本身搞出來的，和google一毛線關係沒有。另外就是最近google本身一些主力產品或者平臺在優先支持語言上，Go老是和java，c/c++，python一塊兒名列其中，grpc就是一個例子等等。因此，以爲Go只是google的一個玩具的人，你的觀點能不能站得住腳，本身掂量吧。 個人我的觀點是： Go顯示已經站住了腳跟(若是是2013年，我仍是不敢說這種話的)，找到了屬於本身的空間，可是比起那些主流的甚至nodeJS來講，仍是使用的不夠普遍。這個語言人爲炒做也罷，一些人認爲的google光環也罷，實際使用也罷，總之： 這個語言已經站住腳跟了，能用於而且已經用於生產環境了，接下來幾年只會一直呈上升勢頭。

我的觀點：

1 一些真正使用go語言的公司：
這些公司在高速發展的同時，Golang也所以在國內逐漸傳播開來。在雲計算時代，從國內Go 語言發展和應用來看，七牛算是國內第一家選 Go 語言作服務端的公司。早在2011年，當Go語法還沒徹底穩定下來的狀況下，七牛就已經選擇將Go做爲存儲服務端的主題語言。關於這點，七牛CEO許式偉談到：編程哲學的重塑是 Go 語言獨樹一幟的根本緣由，其它語言仍難以擺脫 OOP 或函數式編程的烙印，只有 Go 徹底放棄了這些，對編程範式從新思考，對熱門的面向對象編程提供極度簡約但卻完備的支持。Go 是互聯網時代的C語言，不只會制霸雲計算，10 年內將會制霸整個 IT 領域。

2 在中國程序員眼中，谷歌出品必屬精品
確實，在互聯網世界，在開源世界，Google爲咱們貢獻了太多太多。

3 創業公司僞裝高逼格，僞裝geek範兒
The word geek is a slang term originally used to describe eccentric or non-mainstream people; in current use, the word typically connotes an expert or enthusiast or a person obsessed with a hobby or intellectual pursuit, with a general pejorative meaning of a 「peculiar person, especially one who is perceived to be overly intellectual, unfashionable, or socially awkward」.

4 docker異常火爆，帶動了對go語言的關注
Docker是PaaS供應商dotCloud開源的一個基於LXC 的高級容器引擎，源代碼託管在 GitHub 上, 基於Go語言開發並聽從Apache 2.0協議開源。

5 go語言自己的一些特性
部署簡單
併發性好
性能好
。。。

6《go語言從入門到放棄》一書的火爆

GO語言最初的定位就是互聯網時代的C語言，因此，它的基礎哲學也來源於C語言，而C語言的成功正是由於它的簡單。而簡潔的表達方式也會提高程序員的開發效率。

併發性好

幾年前，要實現併發編程並非一件容易的事兒，要想完成併發編程要同時瞭解線程、鎖、Semaphore、CPU緩存方式等等，而多核處理器的普及，讓編程語言更爲注重併發性，而Go語言，能夠在一個進程中執行有數以十萬計的協程，依舊保持高性能。

應用場景符合將來需求

有人猜想，今年10月GO語言增加率如此之高的緣由之一是：Docker的普及。若是真是如此，那麼GO語言將持續如此高的增加率。除此以外，GO語言適用於服務器編程、分佈式系統、網絡編程、內存數據庫和雲平臺，而這些領域正是IT技術將來發展的重要方向。

「我爲何選擇使用Go語言？」

「Go語言能夠說是開發效率和運行效率兩者的完美融合，天生的併發編程支持。」，蘋果核心繫統高級工程師、EGO會員、GopherChina組織者、《Go Web編程》做者謝孟軍說。

當被問到本身爲何如此鍾情於使用Go語言，謝孟軍談到了如下幾個緣由：

學習曲線

它包含了類C語法、GC內置和工程工具。這一點很是重要，由於Go語言容易學習，因此一個普通的大學生花一個星期就能寫出來能夠上手的、高性能的應用。在國內你們都追求快，這也是爲何國內Go流行的緣由之一。

效率

Go擁有接近C的運行效率和接近PHP的開發效率，這就頗有利的支撐了上面你們追求快速的需求。

出身名門、血統純正

之因此說Go出身名門，是由於咱們知道Go語言出自Google公司，這個公司在業界的知名度和實力天然不用多說。Google公司彙集了一批牛人，在各類編程語言稱雄爭霸的局面下推出新的編程語言，天然有它的戰略考慮。並且從Go語言的發展態勢來看，Google對它這個新的寵兒仍是很看重的，Go天然有一個良好的發展前途。咱們看看Go語言的主要創造者，血統純正這點就可見端倪了。

自由高效：組合的思想、無侵入式的接口

Go語言能夠說是開發效率和運行效率兩者的完美融合，天生的併發編程支持。Go語言支持當前全部的編程範式，包括過程式編程、面向對象編程以及函數式編程。程序員們能夠各取所需、自由組合、想怎麼玩就怎麼玩。

強大的標準庫

這包括互聯網應用、系統編程和網絡編程。Go裏面的標準庫基本上已是很是穩定了，特別是我這裏提到的三個，網絡層、系統層的庫很是實用。

部署方便：二進制文件、Copy部署

我相信這一點是不少人選擇Go的最大理由，由於部署太方便了，因此如今也有不少人用Go開發運維程序。

簡單的併發

它包含了下降心智的併發和簡易的數據同步，我以爲這是Go最大的特點。之因此寫正確的併發、容錯和可擴展的程序如此之難，是由於咱們用了錯誤的工具和錯誤的抽象，Go能夠說這一塊作的至關簡單。

穩定性

Go擁有強大的編譯檢查、嚴格的編碼規範和完整的軟件生命週期工具，具備很強的穩定性，穩定壓倒一切。那麼爲何Go相比於其餘程序會更穩定呢？這是由於Go提供了軟件生命週期（開發、測試、部署、維護等等）的各個環節的工具，如go tool、gofmt、go test。

這裏引用知乎裏一個同窗對Go評論的話：最開始準備上線的時候其實內心挺忐忑，畢竟一旦出現故障，不只黑鍋得本身背，面子也上過不去啊。還好結果蠻漂亮，自上線後沒出現過一次突發性BUG，下降運維難度的同時還減小了機器的負載。我相信這也是大多數人用了Go以後的感言。

那麼目前Go還存在哪些缺點呢？如下是我本身在項目開發中遇到的一些問題：

Go的Import包不支持版本，有時候升級容易致使項目不可運行，因此須要本身控制相應的版本信息。比較好的現象是從Go 1.5開始Go對此就有重視了並支持Vendor。

Go的goroutine一旦啓動後，不一樣的goroutine之間切換不是受程序控制，runtime調度的時候須要嚴謹的邏輯，否則goroutine休眠，過一段時間邏輯結束了卻忽然冒出來又執行了，這會致使邏輯出錯等狀況。這個目前無解，應該屬於調度器的優化。

GC延遲有點大，我開發的日誌系統傷過一次，同時在併發很大的狀況下，處理很大的日誌，GC沒有那麼快，內存回收不給力，後來通過Profile程序改進以後獲得了改善。目前來看，GC已經優化的很是好了，給你們看一下Go1.五、Go1.6的GC先後對比圖。

圖3

圖3是Go1.4升級到Go1.5以後的效果，從300ms到了50ms左右。

圖4

圖4是從Go1.5升級到Go1.6，從40ms到了2ms左右，能夠說目前GC基本上不是Go的問題了。

pkg下面的圖片處理庫不少bug，仍是使用成熟產品好，調用這些成熟庫imagemagick的接口比較靠譜。總而言之，從工程的角度上來看，對於大多數後臺應用場景，選擇Golang是極爲明智的選擇。這樣能夠很輕鬆的兼顧運行性能、開發效率及維護難度這三大讓諸多程序猿欲仙欲死的點。

哪些領域在用Go語言？

「在美國市值前20的企業有超過一半正在使用Go」。不只市值前20的企業，國外不少初創企業，都在使用Go語言。近年來，Go語言在中國的關注，也異常火爆。幾乎每一天，都聽到許多人談論到 Go語言。國外甚至有人，專門寫了一篇文章，來分析爲何go在中國如此火：Why is Golang popular in China?： http://herman.asia/why-is-go-popular-in-china

目前，Go語言被普遍應用於各類領域。

軟件開發工具

幾乎全部這幾年出現的軟件開發工具都已經被用 Go語言語言改寫了。我以爲這恐怕預示着什麼。一般，相對於通常的開發小組，小公司的運維小組收到的監管不多。只要是能工做的工具，他們通常就會去用，而不須要獲得誰的批准。對他們來講 Go語言語言工做的很是棒，這是一門靜態類型和編譯型的語言（無需安裝須要上千個依賴的運行庫），並且 Go語言的運行庫也不大，也不用動不動就須要 100-300M的磁盤空間（看看 ruby、jvm 吧）。

比特幣

許多DeferPanic 上的用戶都與比特幣/虛擬貨幣有關。這並不是巧合，整個生態系統的共同點是使用Go語言。

無論你聽到過什麼，比特幣都尚未死掉。不少用例傳統上沒想到過的，可是實際上已經有了很大的成功。咱們的這些用戶須要有高性能和更好的數據安全性的保證，Go語言在這方面顯然是很好的選擇。

容器技術

有趣的是和那些科技人士交談後發現他們竟然不知道今天全部容器技術都是 Go語言寫的，不是 99%，也不是 95%-100%。

全部今天在使用的容器軟件都是 Go語言寫的。

市場營銷人員應該開始用 Go語言原生來替換雲原生。

咱們能夠強調這是有多大（的市場）？即便你不相信容器的炒做，認爲這是一個龐式騙局。當你考慮到全部公司使用 Go語言的人數，而且將來幾年大公司使用 Go語言人數巨大。問你從世界財富五百強的首席信息官那據說他們將要檢修他們系統，你不得不意識到這訂單很大。這不是他們看輕這件事，相反，他們也不會輕易的從中走開，由於這是一個巨大的對時間，金錢以及過程的投資。

微服務

微服務在過去的幾年風靡一時，很多分析師忽略了它們的價值，由於他們並非搞技術的。當你用maven下載了半個互聯網，同時啓動要佔用 800M 虛擬內存，或者當你運行一個 RoR 的應用的時候佔用了 200M，這和 Go語言平均 5-20M 的運行時想比真是相差巨大。這種差距能夠馬上轉換到帳單上，當你公司每月少給 25-30 美金在 AWS 上就顯而易見了。隨着這種激烈的趨勢下去，咱們會看到愈來愈多的公司由於上述理由採用這種模式，而且你能夠打賭即將迎來 Go語言的時代。

商業應用

當談及到一些知道 Docker 的人頗有趣，他們甚至會去投資它在他們並不知道這個是由一個他們從未聽過的 Go語言編寫而成的以前。

歷來自 Battery 的 Adrian （也是來自 Netflix）今年在他與公司的交流中曾經數次說到 Go語言：

「大概四分之三的新東西是用 Go語言寫的 @golang」 – 十二月十四號

L 接着他又提到「幾乎全部新的、有趣的東西都是用 Go語言寫的」.

在他的行業裏面他可能有更好的眼光，由於他參加過不少會議，並如此的接地氣。來自 Mayfield 的 Robin Vasan 甚至在今年的 goper 大會上進行了一次演講在 VC 工做，而且精通 Go語言的 Jerry Chen 曾經出席大會並有良好表現。

今年2月，Go 團隊發佈了 Go 1.8 ，編譯時間比 Go 1.7 提升了約 15％。

技術發展進行時，技術大會怎麼能落下？

Gopher2017大會，StuQ獨家直播！

這個4月，中國最權威和最實力乾貨的 Go 大會——Gopher China 大會來啦！！！致力於爲中國廣大的 Gopher 提供最好的技術大會，Gopher China 每一年都會彙集一批大規模應用 Go 的示範企業分享經驗。

4.15 - 4.16，國內最大最專業的Go大會—GopherChina大會，將在魔都上海舉行。本次大會邀請了空前強大的導師陣容，呈現 Go 在微服務、大數據、金融、Go 內核等多個最前沿主題的技術演講。

他們分別是Google Cloud 工程師Francesc Campoy、嗶哩嗶哩的技術總監毛劍、華爲開源技術專家馬全1、阿里雲工程師聰心、360 工程師郭軍、有贊科技技術專家李文、VMWare中國研發中心雲原生應用首席架構師張海寧、七牛大數據開發高級工程師孫建波……

想知道在此次GopherChina大會上，技術大咖們會有哪些精彩觀點？想知道微服務、大數據、金融、Go 內核的最前沿趨勢？

我爲何放棄Go語言

做者：莊曉立（Liigo）

日期：2014年3月

原創連接：http://blog.csdn.net/liigo/article/details/23699459

轉載請註明出處：http://blog.csdn.net/liigo

有好幾回，當我想起來的時候，老是會問本身：我爲何要放棄Go語言？這個決定是正確的嗎？是明智和理性的嗎？其實我一直在認真思考這個問題。

開門見山地說，我當初放棄Go語言（golang），就是由於兩個「不爽」：第一，對Go語言自己不爽；第二，對Go語言社區裏的某些人不爽。毫無疑問，這是很是主觀的結論。可是我有足夠詳實的客觀的論據，用以支撐這個看似主觀的結論。

文末附有本文更新日誌。

第0節：個人Go語言經歷

先說說個人經歷吧，以免被平白無故地看成Go語言的低級黑。

2009年末，Go語言（golang）第一個公開版本發佈，籠罩着「Google公司製造」的光環，吸引了許多慕名而來的嚐鮮者，我（Liigo）也身居其中，籠統的看了一些Go語言的資料，學習了基礎的教程，因對其語法中的分號和花括號不滿，很快就遺忘掉了，沒拿它當一回事。

兩年以後，2011年末，Go語言發佈1.0的計劃被提上日程，相關的報道又多起來，我再次關注它，[從新評估][1]以後決定深刻參與Go語言。我訂閱了其users、nuts、dev、commits等官方郵件組，堅持天天閱讀其中的電子郵件，以及開發者提交的每一次源代碼更新，給Go提交了許多改進意見，甚至包括[修改Go語言編譯器源代碼][2]直接參與開發任務。如此持續了數月時間。

到2012年初，Go 1.0發佈，語言和標準庫都已經基本定型，不可能再有大幅改進，我對Go語言未能在1.0定型以前更上一個臺階、實現自我突破，甚至帶着諸多明顯缺陷走向1.0，感到很是失望，於是逐漸疏遠了它（因此Go 1.0以後的事情我不多關心）。後來看到即將發佈的Go 1.1的Release Note，發現語言層面沒有太大改變，只是在庫和工具層面有所修補和改進，感到它尚在幼年就失去成長的動力，愈加失望。外加Go語言社區裏的某些人，其中也包括Google公司負責開發Go語言的某些人，其態度、言行，讓我極度厭惡，促使我決絕地離棄Go語言。

在上一個10年，我（Liigo）在我所屬的公司裏，深度參與了兩個編程語言項目的開發。我想，對於如何判斷某個編程語言的優劣，或者說至少對於如何判斷某個編程語言是否適合於我本身，我應該仍是有一點發言權的。

[1]: https://plus.google.com/+LiigoZhuang/posts/CpRNPeDXUDW

[2]: http://blog.csdn.net/liigo/article/details/7467309

第1節：我爲何對Go語言不爽？

Go語言有不少讓我不爽之處，這裏列出我如今還能記起的其中一部分，排名基本上不分前後。讀者們耐心地看完以後，還能淡定地說一句「我不在意」嗎？

1.1 不容許左花括號另起一行

關於對花括號的擺放，在C語言、C++、Java、C#等社區中，十餘年來存在持續爭議，從未造成一致意見。在我看來，這原本就是主觀傾向很重的抉擇，不違反原則不涉及是非的狀況下，不該該搞一刀切，讓程序員或團隊本身選擇就足夠了。編程語言自己強行限制，把本身的喜愛強加給別人，得不償失。不管傾向於其中任意一種，必然得罪與其對立的一羣人。雖然我如今已經習慣了把左花括號放在行尾，但一想到被禁止其餘選擇，就感到十分不爽。Go語言這這個問題上，沒有作到「團結一切能夠團結的力量」不說，還有意給本身樹敵，太失敗了。

1.2 編譯器莫名其妙地給行尾加上分號

對Go語言自己而言，行尾的分號是能夠省略的。可是在其編譯器（gc）的實現中，爲了方便編譯器開發者，卻在詞法分析階段強行添加了行尾的分號，反過來又影響到語言規範，對「怎樣添加分號」作出特殊規定。這種變態作法前無古人。在左花括號被意外放到下一行行首的狀況下，它自動在上一行行尾添加的分號，會致使莫名其妙的編譯錯誤（Go 1.0以前），連它本身都解釋不明白。若是實在處理很差分號，乾脆不要省略分號得了；或者，Scala和JavaScript的編譯器是開源的，跟它們學學怎麼處理省略行尾分號能夠嗎？

1.3 極度強調編譯速度，不惜放棄本應提供的功能

程序員是人不是神，編碼過程當中免不了由於大意或疏忽犯一些錯。其中有一些，是你們集體性的很容易就中招的錯誤（Go語言裏的例子我暫時想不起來，C++裏的例子有「基類析構函數不是虛函數」）。這時候編譯器應該站出來，多作一些檢查、約束、覈對性工做，儘可能阻止常規錯誤的發生，儘可能不讓有潛在錯誤的代碼編譯經過，必要時給出一些警告或提示，讓程序員留意。編譯器不就是機器麼，不就是應該多作髒活累活雜活、減小人的心智負擔麼？編譯器多作一項檢查，可能會避免數十萬程序員從此多年內無數次犯一樣的錯誤，節省的時間不可勝數，這是功德無量的好事。可是Go編譯器的做者們可不這麼想，他們不肯意本身多花幾個小時給編譯器增長新功能，以爲那是虧本，反而減慢了編譯速度。他們以影響編譯速度爲由，拒絕了不少對編譯器改進的要求。典型的因噎廢食。強調編譯速度當然值得讚揚，但若是所以放棄應有的功能，我不同意。

1.4 錯誤處理機制太原始

在Go語言中處理錯誤的基本模式是：函數一般返回多個值，其中最後一個值是error類型，用於表示錯誤類型極其描述；調用者每次調用完一個函數，都須要檢查這個error並進行相應的錯誤處理：if err != nil { /*這種代碼寫多了不想吐麼*/ }。此模式跟C語言那種很原始的錯誤處理相好比出一轍，並沒有實質性改進。實際應用中很容易造成多層嵌套的if else語句，能夠想想這個編碼場景：先判斷文件是否存在，若是存在則打開文件，若是打開成功則讀取文件，若是讀取成功再寫入一段數據，最後關閉文件，別忘了還要處理每一步驟中出現錯誤的狀況，這代碼寫出來得有多變態、多醜陋？實踐中廣泛的作法是，判斷操做出錯後提早return，以免多層花括號嵌套，但這麼作的後果是，許多錯誤處理代碼被放在前面突出的位置，常規的處理邏輯反而被掩埋到後面去了，代碼可讀性極差。並且，error對象的標準接口只能返回一個錯誤文本，有時候調用者爲了區分不一樣的錯誤類型，甚至須要解析該文本。除此以外，你只能手工強制轉換error類型到特定子類型（靜態類型的優點沒了）。至於panic - recover機制，致命的缺陷是不能跨越庫的邊界使用，註定是一個半成品，最多隻能在本身的pkg裏面玩一玩。Java的異常處理雖然也有自身的問題（好比Checked Exceptions），但整體上仍是比Go的錯誤處理高明不少。

1.5 垃圾回收器（GC）不完善、有重大缺陷

在Go 1.0前夕，其垃圾回收器在32位環境下有內存泄漏，一直拖着不願改進，這且不說。Go語言垃圾回收器真正致命的缺陷是，會致使整個進程不可預知的間歇性停頓（Stop the World）。像某些大型後臺服務程序，如遊戲服務器、APP容器等，因爲佔用內存巨大，其內存對象數量極多，GC完成一次回收週期，可能須要數秒甚至更長時間，這段時間內，整個服務進程是阻塞的、停頓的，在外界看來就是服務中斷、無響應，再牛逼的併發機制到了這裏通通失效。垃圾回收器按期啓動，每次啓動就致使短暫的服務中斷，這樣下去，還有人敢用嗎？這但是後臺服務器進程，是Go語言的重點應用領域。以上現象可不是我假設出來的，而是事實存在的現實問題，受其嚴重困擾的也不是一家兩家了（2013年末ECUG Con 2013，京東的劉奇提到了Go語言的GC、defer、標準庫實現是性能殺手，最大的痛苦是GC；美團的沈鋒也提到Go語言的GC致使後臺服務間隔性停頓是最大的問題。更早的網絡遊戲仙俠道開發團隊也曾受Go垃圾回收的沉重打擊）。在實踐中，你必須努力減小進程中的對象數量，以便把GC致使的間歇性停頓控制在可接受範圍內。除此以外你別無選擇（難道你還想本身更換GC算法、甚至砍掉GC？那仍是Go語言嗎？）。跳出圈外，我近期一直在思考，必定須要垃圾回收器嗎？沒有垃圾回收器就必定是歷史的倒退嗎？（可能會新寫一篇博客文章專題探討。）

2016年3月3日Liigo補記：直到2015年末，Go 1.5新GC發佈後數月，仍獲知有大陸圈內知名團隊由於GC的緣由考慮換掉Go語言，很有感觸。當軟件系統逐步發展到更龐大更復雜的時候，Go語言的垃圾回收器(GC)就變成了指不定啥時候會出現的攔路虎，讓人進退兩難。進，暫時沒有確切有效的技術手段對付響應延遲和內存暴漲；退，多年開發付出的心血付之東流損失慘重。語言選型以前多作調查分析，若是必定要用Go語言開發，控制系統規模和複雜度，避開底層的核心業務，多是比較明智的選擇。

1.6 禁止未使用變量和多餘import

Go編譯器不容許存在被未被使用的變量和多餘的import，若是存在，必然致使編譯錯誤。可是現實狀況是，在代碼編寫、重構、調試過程當中，例如，臨時性的註釋掉一行代碼，很容易就會致使同時出現未使用的變量和多餘的import，直接編譯錯誤了，你必須相應的把變量定義註釋掉，再翻頁回到文件首部把多餘的import也註釋掉，……等事情辦完了，想把剛纔註釋的代碼找回來，又要好幾個麻煩的步驟。還有一個讓人蛋疼的問題，編寫數據庫相關的代碼時，若是你import某數據庫驅動的pkg，它編譯給你報錯，說不須要import這個未被使用的pkg；但若是你聽信編譯器的話刪掉該import，編譯是經過了，運行時必然報錯，說找不到數據庫驅動；你看看程序員被折騰的兩邊不是人，最後不得不請出大神：`import _`。對待這種問題，一個比較好的解決方案是，視其爲編譯警告而非編譯錯誤。可是Go語言開發者很執拗，不允許這種折中方案。

1.7 建立對象的方式太多使人糾結

建立對象的方式，調用new函數、調用make函數、調用New方法、使用花括號語法直接初始化結構體，你選哪種？很差選擇，由於沒有一個固定的模式。從實踐中看，若是要建立一個語言內置類型（如channel、map）的對象，一般用make函數建立；若是要建立標準庫或第三方庫定義的類型的對象，首先要去文檔裏找一下有沒有New方法，若是有就最好調用New方法建立對象，若是沒有New方法，則退而求其次，用初始化結構體的方式建立其對象。這個過程頗爲周折，不像C++、Java、C#那樣直接new就好了。

1.8 對象沒有構造函數和析構函數

沒有構造函數還好說，畢竟還有自定義的New方法，大體也算是構造函數了。沒有析構函數就比較難受了，無法實現RAII。額外的人工處理資源清理工做，無疑加劇了程序員的心智負擔。沒人性啊，還嫌咱們程序員加班還少嗎？C++裏有析構函數，Java裏雖然沒有析構函數可是有人家finally語句啊，Go呢，什麼都沒有。沒錯，你有個defer，但是那個defer問題更大，詳見下文吧。

1.9 defer語句的語義設定不甚合理

Go語言設計defer語句的出發點是好的，把釋放資源的「代碼」放在靠近建立資源的地方，但把釋放資源的「動做」推遲（defer）到函數返回前執行。遺憾的是其執行時機的設置彷佛有些不甚合理。設想有一個須要長期運行的函數，其中有無限循環語句，在循環體內不斷的建立資源（或分配內存），並用defer語句確保釋放。因爲函數一直運行沒有返回，全部defer語句都得不到執行，循環過程當中建立的大量短暫性資源一直積累着，得不到回收。並且，系統爲了存儲defer列表還要額外佔用資源，也是持續增長的。這樣下去，過不了多久，整個系統就要由於資源耗盡而崩潰。像這類長期運行的函數，http.ListenAndServe()就是典型的例子。在Go語言重點應用領域，能夠說幾乎每個後臺服務程序都必然有這麼一類函數，每每還都是程序的核心部分。若是程序員不當心在這些函數中使用了defer語句，能夠說後患無窮。若是語言設計者把defer的語義設定爲在所屬代碼塊結束時（而非函數返回時）執行，是否是更好一點呢？但是Go 1.0早已發佈定型，爲了保持向後兼容性，已經不可能改變了。當心使用defer語句！一不當心就中招。

1.10 許多語言內置設施不支持用戶定義的類型

for in、make、range、channel、map等都僅支持語言內置類型，不支持用戶定義的類型(?)。用戶定義的類型無法支持for in循環，用戶不能編寫像make、range那樣「參數類型和個數」甚至「返回值類型和個數」均可變的函數，不能編寫像channel、map那樣相似泛型的數據類型。語言內置的那些東西，到處充斥着斧鑿的痕跡。這體現了語言設計的侷限性、封閉性、不完善，可擴展性差，像是新手做品——且不論其設計者和實現者如何權威。延伸閱讀：Go語言是30年前的陳舊設計思想，用戶定義的東西幾乎都是二等公民（Tikhon Jelvis）。

1.11 沒有泛型支持，常見數據類型接口醜陋

沒有泛型的話，List、Set、Tree這些常見的基礎性數據類型的接口就只能很醜陋：放進去的對象是一個具體的類型，取出來以後成了無類型的interface{}（能夠視爲全部類型的基礎類型），還得強制類型轉換以後才能繼續使用，使人無語。Go語言缺乏min、max這類函數，求數值絕對值的函數abs只接收/返回雙精度小數類型，排序接口只能藉助sort.Interface無奈的迴避了被比較對象的類型，等等等等，都是沒有泛型致使的結果。沒有泛型，接口很難優雅起來。Go開發者沒有明確拒絕泛型，只是說尚未找到很好的方法實現泛型（能不能學學已經開源的語言呀）。現實是，Go 1.0已經定型，泛型尚未，那些醜陋的接口爲了保持向後兼容必須長期存在着。延伸閱讀：HN網友抱怨Go沒有泛型。

1.12 實現接口不須要明確聲明

這一條一般是被看成Go語言的優勢來宣傳的。可是也有人不贊同，好比我。若是一個類型用Go語言的方式默默的實現了某個接口，使用者和代碼維護者都很難發現這一點（除非仔細覈對該類型的每個方法的函數簽名，並跟全部可能的接口定義相互對照），天然也想不到與該接口有關的應用，顯得十分隱晦，不直觀。支持者可能會辯解說，我能夠在文檔中註明它實現了哪些接口。問題是，寫在文檔中，還不如直接寫到類型定義上呢，至少還能獲得編譯器的靜態類型檢查。缺乏了編譯器的支持，當接口類型的函數簽名被改變時，當實現該接口的類型方法被無心中改變時，實現者可能很難意識到，該類型實現該接口的隱含約束事實上已經被打破了。又有人辯解說，我能夠經過單元測試確保類型正確實現了接口呀。我想說的是，明明能夠經過明確聲明實現接口，享受編譯器提供的類型檢查，你卻要本身找麻煩，去寫本來多餘的單元測試，找虐很爽嗎？Go語言的這種作法，除了減小一些對接口所在庫的依賴以外，沒有其餘好處，得不償失。延伸閱讀：爲何我不喜歡Go語言式的接口（老趙）。

1.13 省掉小括號卻省不掉花括號

Go語言裏面的if語句，其條件表達式不須要用小括號擴起來，這被做爲「代碼比較簡潔」的證據來宣傳。但是，你省掉了小括號，卻不能省掉大括號啊，一條完整的if語句至少還得三行吧，人家C、C++、Java均可以在一行以內搞定的（能夠省掉花括號）。人家還有x?a:b表達式呢，也是一行搞定，你Go語言用if else寫至少得五行吧？哪裏簡潔了？

1.14 編譯生成的可執行文件尺寸很是大

記得當年我寫了一個很簡單的程序，把全部系統環境變量的名稱和值輸出到控制檯，核心代碼也就那麼三五行，結果編譯出來把我嚇壞了：EXE文件的大小超過4MB。若是是C語言寫的一樣功能的程序，0.04MB都是多的。我把這個信息反饋到官方社區，結果人家不在意。是，我知道如今的硬盤容量都數百GB、上TB了……可您這種優化程度……怎麼讓我相信您在其餘地方也能作到不錯呢。（再次強調一遍，我全部的經驗和數據都來自Go 1.0發佈前夕。）

1.15 不支持動態加載類庫

靜態編譯的程序固然是很好的，沒有額外的運行時依賴，部署時很方便。可是以前咱們說了，靜態編譯的文件尺寸很大。若是一個軟件系統由多個可執行程序構成，累加起來就很可觀。若是用動態編譯，發佈時帶同一套動態庫，能夠節省不少容量。更關鍵的是，動態庫能夠運行時加載和卸載，這是靜態庫作不到的。還有那些LGPL等協議的第三方C庫受版權限制是不容許靜態編譯的。至於動態庫的版本管理難題，能夠經過給動態庫內的全部符號添加版本號解決。不管如何，應該給予程序員選擇權，讓他們本身決定使用靜態庫仍是動態庫。一刀切的拒絕動態編譯是不合適的。

1.16 其餘

不支持方法和函數重載（overload）
導入pkg的import語句後邊部分居然是文本（import 」fmt」）
沒有enum類型，全局性常量難以分類，iota把簡單的事情複雜化
定義對象方法時，receiver類型應該選用指針仍是非指針讓人糾結
定義結構體和接口的語法稍繁，interface XXX{} struct YYY{} 不是更簡潔嗎？前面加上type關鍵字顯得羅嗦。
測試類庫testing裏面沒有AssertEqual函數，標準庫的單元測試代碼中充斥着if a != b { t.Fatal(...) }。
語言太簡單，以致於不得不放棄不少有用的特性，「保持語言簡單」每每成爲拒絕改進的理由。
標準庫的實現整體來講不甚理想，其代碼質量大概處於「基本可用」的程度，真正到企業級應用領域，每每就會暴露出諸多不足之處。
版本都發展到1.2了，goroutine調度器依舊默認僅使用一個系統線程。GOMAXPROCS的長期存在彷佛暗示着官方歷來沒有足夠的信心，讓調度器正確安全地運行在多核環境中。這跟Go語言自身以併發爲核心的定位有致命的矛盾。（直到2015年下半年1.5發佈後纔有改觀）
官方發行版中包含了一個叫oracle的輔助程序，與Oracle數據庫毫無關係，卻徹底無視二者之間的名稱混淆。

上面列出的是我目前還能想到的對Go語言的不爽之處，畢竟時間過去兩年多，還有一些早就遺忘了。其中一部分當然是小不爽，可能忍一忍就過去了，可是不少不爽積累起來，總會時不時地讓人難受，時間久了有自虐的感受。程序員的工做生活原本就夠枯燥的，何須呢。

必需要說的是，對於其中大多數不爽之處，我（Liigo）都曾經試圖改變過它們：在Go 1.0版本發佈以前，我在其官方郵件組提過不少意見和建議（甚至包括提交代碼CL），極力力排衆議，能夠說付出很大努力，目的就是但願定型後的Go語言是一個相對完善的、沒有明顯缺陷的編程語言。結果是使人失望的，我人微言輕、勢單力薄，不可能影響整個語言的發展走向。1.0以前，最佳的否認自我、超越自個人機會，就這麼遺憾地錯過了。我最終發現，不少時候不是技術問題，而是技術人員的問題。

第2節：我爲何對Go語言的某些人不爽？

這裏提到的「某些人」主要是兩類：1、負責專職開發Go語言的Google公司員工；2、Go語言的推崇者和腦殘粉絲。我跟這兩類人打過不少交道，不勝其煩。再次強調一遍，我指的是「某些」人，而不是全部人，請不要對號入座。

Google公司內部負責專職開發Go語言的核心開發組某些成員，他們傾向於閉門造車，執拗己見，對第三方提出的建議不重視。他們經常掛在嘴邊的口頭禪是：現有的作法很好、不須要那個功能、咱們開發Go語言是給Google本身用的、Google不須要那個功能、若是你必定要改請fork以後本身改、別幹提意見請提交代碼。不少言行都是「反開源」的。經過一些具體的例子，還能更形象的看清這一層。就留下做爲課後做業吧。

我最不能接受的就是他們對1.0版本的散漫處理。那時候Go還沒到1.0，初出茅廬的小學生，有很大的改進空間，是全面翻新的最佳時機，彼時不改更待什麼時候？1.0是打地基的版本，基礎不牢靠，等1.0定型以後，到處受到向後兼容性的牽制，束手縛腳，每前進一步都阻力重重。急於發佈1.0，過早定型，留下諸多遺憾，彰顯了開發者的功利性強，在技術上不追求盡善盡美。

Go語言的核心開發成員，他們平常的開發工做是使用C語言——Go語言的編譯器和運行時庫，包括語言核心數據結構和算法map、channel、scheduler，都是C開發的——真正用本身開發的Go語言進行實際的大型應用開發的機會並很少。雖然標準庫是用Go語言本身寫的，但他們卻沒有大範圍使用標準庫的經歷。實際上，他們缺乏使用Go語言的實戰開發經驗，每每不知道處於開發第一線的用戶真正須要什麼，沒法作到設身處地爲程序員着想。缺乏使用Go語言的親身經歷，也意味着他們不能在平常開發中，及時發現和改進Go語言的不足。這也是他們每每自我感受良好的緣由。（2016年5月15日補記：2015年8月Go 1.5版本以後再也不使用C語言開發。）

Go語言社區裏，有一大批Go語言的推崇者和腦殘粉絲，他們知足於現狀，不思進取，到處維護心中的「神」，容不得批評意見，不支持對語言的改進要求。當年我對Go語言的不少批評和改進意見，極少獲得他們的支持，他們不但不支持還給予打擊，我就納悶了，他們難道不但願Go語言更完善、更優秀嗎？我後來才意識到，他們跟喬幫主的蘋果腦殘粉絲們，言行一脈相承，具備極端宗教傾向，神化主子、打擊異己真是竭盡全力呀。簡簡單單的技術問題，就能被他們上升到意識形態之爭。現實的例子是蠻多的，有興趣的到網上去找吧。正是由於他們的存在，致使更多理智、清醒的Go語言用戶沒法真正融入整個社區。

若是一個項目、團隊、社區，處處充斥着讚美、孤芳自賞、自我知足、不思進取，排斥不一樣意見，拒絕接納新方案，我想不到它還有什麼前進的動力。逆水行舟，是不進反退的。

2016年5月15日補記：@netroby：「Golang社區的神經病和執拗，我深有體會。我曾經發過Issue，請求Golang官方，能爲doc加上高亮，這樣瀏覽器閱讀文檔的時候，能快速閱讀代碼參考。可是被各類拒絕. 他們的理由是不少開發者不喜歡高亮。」 https://github.com/golang/go/issues/13178

2016年5月15日補記：C++天才人物、D語言聯合創始人Andrei Alexandrescu：「Go所走的路線在一些問題上持有極其強硬和死板態度，這些問題有大有小。在比較大的方面，泛型編程被嚴格控制，甚至貶低到只有"N"個字；有關泛型編程的討論都是試圖去勸阻任何有意義的嘗試，這已經足夠讓人以爲恥辱。從長遠來看，技術問題的政治化是一種極其有害的模式，因此但願Go社區可以找到修正它的方法。」 http://www.csdn.net/article/2015-12-20/2826517

第3節：還有比Go語言更好的選擇嗎？

我始終堅持一個很有辯證法意味的哲學觀點：在更好的替代品出現以前，現有的就是最好的。失望是沒有用的，抱怨是沒有用的，要麼接受，要麼逃離。我曾經努力嘗試過接受Go語言，失敗以後，註定要逃離。發現更好的替代品以後，無疑加速了逃離過程。還有比Go語言更好的替代品嗎？固然有。做爲一個屌絲程序員，我應該告訴你它是什麼，可是我不說。如今還不是時候。我如今不想把這兩門編程語言對立起來，引起另外一場潛在的語言戰爭。這不是此文的本意。若是你非要從現有信息中推測它是什麼，那徹底是你本身的事。若是你原意等，它或許很快會浮出水面，也未可知。