如何評價 Golang 1.5 更新？

01-06

Go 1.5 Beta1 發布，完全使用 Go 編寫的 Go
由此看來，Golang 1.5 是一個大的改動，會對軟體生態帶來什麼樣的影響?

我覺得最大的意義應該是1.5的GC的STW時間明顯下降了。從我之前在wandoulabs/codis · GitHub 的測試結果來說，client並發數比較低的時候最大延遲基本上取決於STW的時間，在我自己的macbook上測，1.3和1.4的最大延遲是4ms和7ms，而1.5不到1ms。為了實現並發收集，1.4里給指針加了個write barrier從而影響了性能，然而1.4的並發收集又沒做，於是1.4變成了一個半成品，性能（吞吐）很多場景比1.3差，而GC的停頓時間又沒減少，非常蛋疼……

另外那條「默認 Go 程序使用 GOMAXPROCS 變數來設置CPU核數，之前默認是1」，並不是單純的一個默認值的改動讓你減少一行蛋疼的代碼這麼簡單。他基於一個前提是現在goroutine的調度器的性能已經越來越好。見https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit ，如果調度器性能不行，在一些場景可能會出現一種情況，就是在goroutine數量相同的情況下，用的CPU越多也就是開的線程越多，性能反而變差（見裡面的表格）。而go的開發者目前認為，1.5的調度器性能nb了很多，在各種測試場景上已經不會導致多核比單核還差很多，於是改了默認值。

沒有模板, 差評. 團隊還在糾結么? 我們要糾結慘了, 沒模板寫出來代碼一點都不優雅和高效

說好的動態庫支持呢?

編譯速度又要下降一些了, 運行速度下降, 但是因為垃圾回收並發, 所以應該還好

"全新的 go tool trace 命令支持細粒度的應用執行跟蹤" &<- 這貨不知道是不是可以跟蹤

支持動態鏈接庫，這個也是很重大的改變。

不知道是否支持動態載入go函數或者package，如果支持就更好了。

1.5最大的意義還是自舉，其他方面也有按部就班的改進，但談不上突破。有人認為自舉只是個象徵，其實不然，那在很大程度上可以讓開發組更專註工作，可以預期之後的開發會加速。

穩步的向前發展感覺是golang的團隊風格，先給個能用但也不是太差的，然後逐步的改進。

golang 這個做法沒啥實際意義吧，只是繼續完善吧，之前動態鏈接庫都不支持？所謂的什麼微線程也是騙人的，就是一個大數組而已，很多人已經用少量C++代碼就實現了對應的方法。

至少對面向對象的人來說C++11/14 、 Dlang 、 Rust 更適合，並且每個語言都有豐富的特性。

Golang:：低性能、簡陋的語法特性、嚴重依賴標準庫做東西。

優點：簡單、標準庫功能多。