最近看到GO語言吵得沸沸揚揚的，這裏也看了下GO語言相關，有很多話想說，不吐不快的那種。
2021年的今天，諸多語言都在百家爭豔，如同過去的諸子百家般，但是每個語言的出生都是有着它的使命。
比如C語言的出現時爲了解決彙編或者B語言的晦澀難懂，過多的代碼量，將大部分的工作留給編譯器去解決。
C++的出現解決了C類語言的不人性化，即引入了面向對象的思想。
JAVA、Python、PHP等更高級的語言則去掉了C和C++的不通人性的一面，也即較爲難理解的一面，比如指針、運算符重載等等騷操作，降低了學習成本，讓語言越來越人性化。
其實就是讓門檻越來越低，內卷越來越嚴重。
比如Java的spring套系的出現，讓JavaSE的基礎都幾乎不用學精。
只需要瞭解if、else、map、list、set等等CRUD必備的操作外，其餘壓根都不用懂，直接上高併發項目。
畢竟再怎麼爛的代碼，多加幾臺機器，部屬個集羣總能撐吧，至少小公司就這樣。
那麼，來聊聊GO語言吧。
這個語言的出生就是帶着取代C++和C去的，保留着指針，結構體，接口，去掉了模板類也即泛型。
去掉了try catch，去掉了重載，去掉了宏定義等等特性，本着簡單易上手的目標去的，而且引入goroutine和channel。
讓編寫高併發不在那麼複雜，畢竟誰都不想去pthread_create等等的一堆操作吧，直接go xxx就異步處理了，多騷。
而且Go語言的協程堆棧動態擴張，隨隨便便就是成百上千個協程，這確實牛逼，畢竟實現了Linux一直想實現的M:N的模型，也即多個內核線程，多個User Space的線程。
but，重要的事情要說三遍，but，but，but，很多人開始不管任何場景，直接選型用GO，這好嗎？這不好！
GO語言誠然有很多優勢：簡單易上手，高併發性能，編譯快，編譯後由於直接是機器碼所以代碼很小。
但是問題來了，GO語言能代替C去編寫Linux內核嗎？想都不用想，不可能。每個語言都有它適用的地方。
那麼就來聊聊大家最關心的吧，用GO語言來代替Java編寫Web後端業務邏輯合適嗎？
我的結論是部分合適，部分不合適。
就如同DDD裏說到的三種模型：事務驅動，MVC，DDD是根據不同業務複雜度來選定。
隨着業務複雜不斷增加我們可以選擇使用DDD來進行設計，但是對於中小型公司來說選用MVC的較多。
而事務驅動型也即原生Servlet+JDBC的方式我想在如今沒人用了吧。
但是我可以告訴大家一個結論當你選擇使用GO語言來編寫業務的時候，這就是事務驅動型的開發，也即使用GO語言來面向過程編程，這好嗎？
還可以，對於小型業務來說，快速開發何樂而不爲，一個go xxx各種異步，而且沒有Java生態那麼多配置，直接import庫函數 CRUD return json就行了。
誠然，我經常說的過去，我們使用面向對象的語言來寫面向過程，就如同用Java的編寫MVC的框架一樣，那麼現在GO語言了，沒有面向對象，別給我說接口，我這裏說的面向對象特性。
所以各位熟知的設計模式，很多無法套在go上使用，畢竟這個語言的使命就是C++而不是JAVA。
所以GO語言如果繼續發展，不管怎麼樣它肯定會佔據C++的一些領域，把C逼到最底層，把JAVA逼到更上層，更貼合於業務處理。
最終我的結論是：GO語言誠然厲害，但是在業務處理方向上和業務架構上，JAVA還是一個王者。
GO語言你的目標是C++、RUST、python，但是業務處理還期待你的發展。
希望在以後對於大型業務場景上能夠看到GO的聲影，目前GO最適合的場景是業務邏輯不復雜的中間件場景。
