golang年度使用總結，簡潔不簡單

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

時間過得好快，比較正式的使用go語言，已經接近300天了。這期間，go從1.5發展到了1.7，自己因為興趣+責任，來到了新的團隊，再次從事曾經非常熟悉的開發工作，充實！

竟然在玩scala之後，用了go語言

最初瞭解go語言，還是13年原單位一個項目。在不涉及到資料庫操作的情況下，技術團隊用.net竟然無法支援500/s的tcp峰值請求。本欲撿起Java，結果無意中知道了go。發現，用go的select非常非常簡單。但因為其編程思想和傳統OO差別很大，極不習慣，就沒有跟進。
再次接觸就是2015年，這期間正癡迷Scala，加入了一些scala的群。喜歡scala比較簡單：
1. 語言精鍊，代碼優雅
scala的模式識別、類型推斷實在是太舒服了，利用lambda（這個java8也有，但scala更純粹）、集合庫，幾行代碼就可做不少事。而且，好多設計模式的東西，在文法上就可以處理。比如Null Object可以用Option直接替代。代碼越少，問題越少，是吧！
2. 入門陡峭，喜歡高智商
好多人都感覺這語言入門比較難，主要在FP思維模式與傳統過程式思維不同。
3. 分布式actor模式，簡化了多伺服器的同步
從設計上，actor模型確實非常不錯，加上akka架構，在多伺服器之間可以簡化服務發現、訊息分配的基礎架構工作。這對於業務開發確實提供了很大的提升。因為自己在這塊沒經驗，不好評價其具體效能。
這期間，最讓人蛋疼的就是SBT。本來SBT是個好東西，但下載太太太慢了。這本來與工具無關，但在天朝，必須折騰，你懂的！
然而，說再多的好處都沒用。回來創業的朋友（我現在所處團隊）做遊戲，招聘有經驗的scala程式員沒成功，再考慮用戶端基本都是c、c++經驗，技術路線盡量貼合，就再次回到了go。都說go簡單，是吧！？事實如此？

對go語言的對比評價

客觀的說，目前半年，服務端開發還算順利。偶有閑暇，還是會看看scala，也很喜歡與go做對比。
作為一門語言，當團隊選擇的時候，考慮的一般是工具與資源，文法難度，效益待遇。

工具與資源

誰都知道go是google搞著玩的，scala則是Lightbend（原來叫做typesafe）的安家之本。想都不用想，兩者出生基本不是一個層次。客觀而言，工具與資源與語言的發起單位的商業化程度有關。
- 開發工具
開發工具方面，除了LiteIDE，其餘都是以外掛程式方式在Idea、Eclipse、Sublime等上運行。個人主要用於Idea，因為重構非常方便，go的外掛程式更新也很快，基本上晚上提交feature之後，睡一覺，就已經處理了。但距離Scala，工具支援程度相差一個層次。比如修改了介面，外掛程式是不會重構“實作類別”的介面方法。一方面，scala外掛程式是官方的；此外，go的介面模型與java系的不同，沒有顯式定義，語義推導要難的多。
- 第三方資源
資源方面，最著名的docker以外，etcd、consul、groupcache、nsq都非常不錯。個人目前用了consul，另外的簡單研究過代碼，但距離使用還有段時間。相對於scala的spark、akka、play、Spray這幾種，go的架構gin、beego、xorm等等，其實都不錯，但側重於局部功能，不及scala的全面，還沒發現分布式資料處理架構。

語言文法

1. 文法二義性少，上手容易。
   go的網路底層封裝好，無明顯bug（當然http2.0還待完善）。除了defer與go、chan之外，代碼無特色。缺少三元操作符、泛型、枚舉，代碼多了會感覺很囉嗦。也許正因為如此，任何人都能夠迅速上手。

2. 對設計模式的依賴依然很強。後期提升比scala難。
   相對於scala在文法階段就封裝了大量模式，go的代碼要原始一些，要寫出漂亮的程式，就得費點功夫。要做出好的服務端，原來的設計模式、架構模式，以及其他類似C語言、linux的使用積累也很重要。相對於scala，後期的成長曲線要陡峭一些。成為宗師，沒有捷徑。

   • 比如：判斷集合不同項
     找出兩個集合的不同，scala只需要幾行，而go語言，試試20行能否搞定。
   • 比如：設定執行的結束時間點或者強制退出
     scala基本是在文法或者actor模型中會有大量講解，而go則是利用csp來做，涉及到複雜業務要考慮封裝。事實上，官方源碼中的context包已經提供了一種模式，非常巧妙。可惜，介紹的比較少，需要自己去探尋，學習成本不比scala低。依然要高智商！

3. 代碼閱讀難度
   因為golang的代碼格式是強制性的，基本上閱讀起來比好多語言容易。但涉及到運用了channel的模組，因為非常靈活，有的coder寫出來的代碼，不問一問，真的不懂。^ _ ^這個涉及到代碼構架風格，又沒有在原來偏OO的《設計模式》中有過論述，我想以後應該會有一些好的經驗方法。

前途，錢途

好多人學習一門語言，不是因為興趣，而是待遇。這是現實，不得迴避。我自己認為，絕大部分不可能精通兩門，尤其思維模型都不同的開發語言。所以，面臨選擇很正常。
個人認為，待遇與語言無關，而與行業、具體單位效益、運氣相關。前段時間面了一位碩士研究生，網路傳輸裝置嵌入式開發15年，待遇只有6500，不如我們現在團隊從事服務端開發不到1年的專科畢業生。同行業不同單位的就不說了，傳統領域中，央企、事業單位，與私營企業的對比，那是黑白一樣的分明。

Scala還是go

無論什麼開發語言，除了文法和部分架構，大部分模式、架構、以及專業背景知識是相同的。語言不同，更多體現在於結合了工具、生態鏈之後，各有擅長的一面。很多時候，語言選擇，在於業務需要和團隊基礎。
1. 業務方面
同屬於服務端的程式，scala側重於資料分析預先處理，集合庫太方便了。其他的業務處理，包括行業應用，go並不會其實沒什麼區別。如果是遊戲開發、物聯網，go還更適合一些。想想看，256M的運行記憶體，就可以很輕易的做到5K以上的長串連+記憶體業務處理，是否很振奮！
2. 團隊方面，
如果團隊允許1年左右的時間折騰，java資源很熟悉，有大量的伺服器資源，選擇Scala不錯。原諒我，我始終認為scala的actor模型非常佔用資源。本質上，scala只是從文法上封裝了Reactor（Proactor）架構+Bridge（或反射）來實現訊息分發與響應（akka還封裝了服務發現，與consul一樣用的gossip協議）。只是我們顯示的看到這個架構而已。不過，面試scala程式員的時候，篩選成本低很多，這其實是個優勢。
如果三個月就得出個大並發的服務端，團隊成員C（C++）比較多或者成員層次不齊，老闆在乎伺服器費用。go的選擇不錯。這玩意就好比國外的高考，寬進嚴出。沒有優秀的代碼，總比沒有代碼好吧？！難題在於，golang的業務實現太靈活，如果有人說搞過一年go，價碼不好判別。

對我而言，兩門語言都非常喜歡。scala的文法封裝了大量的設計模式，這大大減輕了開發成本，側重於“用”。而go語言則勝在文法簡單卻又不失亮點：靜態部署、多傳回值、函數+閉包、簡單的並發+訊息通道，更側重於“創造”。也正因為go語言核心文法的東西不多，到了中後期，做出好的程式架構要比scala燒腦。要真的能把csp玩轉，還需在《設計模式》之外需要積累很多經驗，需要繼續努力！

對go的期許，別只是Better C

要把一門語言玩得轉不容易，個人也看好go語言的發展，但目前的它相對於迅速發展的swift、rust，就好比簡陋的毛胚房。據說golang1.7支援pkg包直接編譯，這獨立開發商提供了可能。個人希望要是能儘快提供以下幾點就好了：

1. 統一的包管理
   缺乏明確顯示的版本，依賴的完整性無法校正，一直是團隊面臨的工程問題。迫切需要類似於marven、sbt這樣的存在。godep、govendor、glide、gvt……太多太多，八仙過海。一個，統一，即可。
2. 泛型、枚舉支援
   都說java的泛型其實內部也是動態轉換，但編譯期發現問題不是要更好一些嗎？論壇提到了golang 2支援，不知道什麼時候。
   至於枚舉，儘管可以通過類型定義做簡單驗證，但依然開放式，限制太少。go不是強調一致嗎？
3. 更多的資料結構基本庫
   目前，container容器內僅有雙向鏈表、環形鏈表、堆。紅/黑樹狀結構或AVL樹，隊列，明確的棧……，沒有。依賴於第三方，或者照著教材寫一個，始終麻煩。
4. 三元操作符
   這個本來只是個細節，但渴望這個文法糖。否則看到if就意味著3-5行。（或許會扯到隱式轉換問題，這個我就不管了。）
5. 其他
   如果可能，lambda、FP、集合庫，我也非常非常喜歡。但願，別讓偶做夢太久！

雜七雜八寫了不少，臨時想的，沒太梳理，就這樣吧。