讀 《我為什麼放棄Go語言》 有感

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

　　最近又熟悉了下go語言，發現go語言還有許多設計不好的地方，然後又讀到了《我為什麼放棄Go語言》這篇文章， 對於某些方面，我還是比較認同的。 

這篇文章總結了十六點，如下：

1.1 不允許左花括弧另起一行

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

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

1.4 錯誤處理機制太原始

1.5 記憶體回收行程（GC）不完善、有重大缺陷

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

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

1.8 對象沒有建構函式和解構函式

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

1.10 許多語言內建設施不支援使用者定義的類型

1.11 沒有泛型支援，常見資料類型介面醜陋

1.12 實現介面不需要明確聲明

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

1.14 編譯產生的可執行檔尺寸非常大

1.15 不支援動態載入類庫

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資料庫毫無關係，卻完全無視兩者之間的名稱混淆。

 

　　接著我又看到了許式偉的《Dive into Golang》，裡面介紹了很多Go語言的坑，這就 反應了這門語言設計不好的地方，

包括：

　　1. 切片（slice）的坑，

　　　　切片簡單地說就是一種很簡單的資料結構 struct{ptr, len, cap}，ptr表示指向某一個數組的指標（注意：這裡是固定長度的數組），len表示當前切片本身儲存資料元素的長度，cap表示此切片當前能儲存的資料元素容量。不同的切片中的ptr可能指向同一個數組的中的各個元素的地址，因此，在對某個slice做操作的時候，ptr指向數組元素的值發生變化，其他slice的也可以看到。

arr := [6]int{0, 1, 2, 3, 4, 5}slice := arr[1:3]slice2 := slice[1:3]fmt.Println(slice)fmt.Println(slice2)        // 結果輸出分別為        [1 2]         [2 3]

　　2. 閉包

　　　　注意，閉包對原環境都是引用，而不是拷貝值，因此一個閉包運行結果，要依賴於閉包運行那個時刻原環境的值，而不是建立閉包時刻原環境的值。

app := func(in int, out int, args []int) {fmt.Println(in, out, args)}args := []int{1, 2}app2 := func(in int, out int) {app(in, out, args)}args = []int{4, 5}app2(4, 5)       

　　　　運行結果為 4 5 [4 5]

　　3. 通道（channel），本質就是一個訊息佇列，裡面會使用到Mutex互斥。

　　　　不要使用channel做互斥原子物語，channel可能會有錯誤，所以讀取channel最好使用select操作

 

　　王垠對Go語言的 吐槽