java太卷了？

藍海永遠值得嘗試。當然golong其實已經發展挺久了，算不算藍海看機緣。

我個人對golang是持支持態度的。那天和同事聊天，另兩個人對golang都持保留態度。仨人都算是java碼農吧。他們的理由是：golang第三方庫的質量經常有問題。也不如java的穩定。性能上也確實沒啥大優勢。而且其實golang優化的空間并不大。跟java你不可能去干擾jit一樣，golang本身并不需要你優化，要優化就是看看profiling，找到主要矛盾，看看能不能換個做法而已。和c++可以likely，unlikely的折騰不是一個意思。

golang我個人覺得做工具是真好用。協程的原生支持讓kotlin哭暈在廁所。所謂的大型系統，我沒參與過，沒發言權。但，以geth、consul等的成功來看，golang起碼不差。而且從有逼格的解決問題角度，golang做得不錯的。

你可以吐槽golang的語法如何坑，但人家是拼標準庫的。人家也不想ioc。人家所有東西一定要打在一起。這是人家的設計理念。

從未來市場說，我覺得起碼在游戲后端開發上，golang較java有理論上的優勢（開發+運行時）。其他只要是io密集型的，都比java有一定的開發效率優勢。至于是否適合計算密集型呢...我只能說，拋開極端的混合c程序之外，在直接用golang開發算法實現上，其實golang也有一點點的優勢：golang允許多返回值。我曾經寫過一點兒手動的數學規劃的代碼，趕腳golang比java寫起來順。

golang的短板，就是表達復雜的OO模型結構。interface這個玩意兒吧...繼承、抽象工廠疑似是一點兒脾氣都沒有。但反過來想：你難道打算用golang搞窗口控件繪制嗎？如果不打算搞個golang的dom瀏覽器，其實生活里其他可能的用處也許就是地圖數據的使用實例，如a star了...而且還可以用通用樹結構來解決問題。

OO的那種繼承樹，其實大部分都屬于提前所說的“次要復雜度”的范疇。golang疑似就是為了解決主要復雜度而生的。這句話有雙面：好是解決主要問題，孬是軟件彈性靠人維護。所以才說做工具是絕佳的。

至于怕卷找藍海...比別人強，哪里都是藍海。比別人弱，你就是紅海。