2021年最後一天，我在公眾號發表了文章《Dubbo為什麼用Go重寫》，在各個平臺的閱讀量和開啟率都挺高，也有各位大佬紛紛轉載，在這裡也順便感謝各位大佬。
雖然自己公眾號沒有開通留言，但我也會去看其他平臺或轉載文章的評論。
我發現大家的注意力更多的是在程式語言上，比如下面這些：
看了這些評論想起了一個段子：
某女：你能讓這個論壇的人都吵起來，我今晚就跟你走。
某軟體工程師：PHP是最好的語言！
某論壇真的就炸鍋了，各種吵架……
某女：服了你了，我們走吧，你想幹啥都行。
某軟體工程師：今天不行，我一定要說服他們，PHP必須是最好的語言…
——段子來源於網路
雖然是個段子，但我也想通了為什麼這篇文章的開啟率和閱讀量如此之高。
文章有大段篇幅在說Java和Go語言，而程式語言之爭歷來都是程式設計師的談資。
但這並不是我的本意，程式語言只是一個背景，可以有各種各樣的理由選擇一個語言，況且現實情況已是如此，所以後續的如何在Go和Java之間架起橋樑才是重點。
不過已經說到這裡，也可以多扯一點，我自己是數學系畢業，所以大學也沒怎麼學程式語言，畢業時選了一個非常容易入門的語言，就是上面段子中的PHP。
後來大環境都是Java，所以也轉了Java，一開始用Java寫業務，後來做中介軟體，再後來跳槽來了現在的公司，也寫起了Go。
如果非要評價Java和Go，我覺得Java的生態非常完備，有幾乎所有網際網路公司需要的解決方案，引用一篇文章裡的話
我以為用Java適合做架構這事應該是常識了。
我解釋一下吧：首先，小型的專案用什麼語言都行，愛用什麼用什麼。
但是，真正的企業級架構就不一樣了，其中並不僅僅只是 RESTful API 或 RPC，還有各種配套設施和控制系統。
比如：應用閘道器，服務發現、配置中心、健康檢查、服務監控、服務治理（熔斷、限流、冪等、重試、隔離、事務補償）、Tracing監控、SOA/ESB、CQRS、EDA……
這些東西在非 Java 的技術棧體系內，很難看到全貌，Java 強大的生態環境，就是讓你把注意力放到更高層次的架構和業務上來的。
另外千萬不要覺得，整幾個服務 RPC 一下，加個快取，加個佇列，就能叫架構，那只是系統整合罷了。
雖然這段話有些絕對，Go生態也在奮力追趕，但就目前的情況來看，確實是這樣。
我也混跡在各個技術群裡潛水，有一次看到一個群裡在討論Java的Spring框架，有個寫Go的同學這麼說：
Spring不就是個Web框架嘛
我覺得他對Java的瞭解太少了，Spring還真就不是一個Web框架，但我忍住了，沒有反駁。
Go也有它的長處，比如協程排程模型、比如啟動速度、記憶體佔用等等。
你別小看協程（雖然Java也快有協程了，但離我們還有點遠），它背後的顯示出的是思想的轉變，比如Go提倡不要通過共享記憶體來通訊，而應該通過通訊來共享記憶體，在Java中，基本就是通過共享記憶體來通訊，這就導致一個問題，多執行緒訪問共享記憶體必須加鎖。
但Go中建議通過channel來通訊，你可能會說，在Java中也有BlockQueue啊。還不一樣，BlockQueue通訊本質上還是對共享內容加鎖，但Go的協程排程模型下，channel就可能實現無鎖。
我記得在我剛工作那會，遇到一位前輩，當時我還在寫PHP，他建議我可以嘗試轉Java，我當時說，語言不過是一個工具。
現在我覺得這句話是有毛病的，語言不光是一個工具，它也凝結了一些程式設計思想，比如PHP的程式模型，Java的執行緒模型，Go的協程模型。在這些模型下，你能做的事可能就不一樣。
比如我在學Go的Benchmark的時候，就覺得Java的Benchmark要比Go實現的嚴謹不少，不愧是工業級語言。
又比如Go的協程排程，在IO密集型下，排程效率比Java優了不少。
再比如在協程排程模型的加持下，Go的物件池效能優於Java，channel效率比Java的BlockQueue高。
總之，我們在力所能及的範圍儘可能地多瞭解其他語言，對比他們的異同，也許對你下次的技術選型就有一些啟發。
這也是我第一次寫這種主觀性較強的文章，在此特地求一個贊+在看，後面我也多扯扯淡。
搜尋關注微信公眾號"捉蟲大師"，回覆關鍵字「Nacos」送你一本《Nacos架構與原理》電子書，Dubbo資料也在準備中，不想錯過可以點個關注。