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資料也在準備中，不想錯過可以點個關注，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/418072.html
標籤：其他
下一篇：Go之Logrus用法入門