2004 年進入華為，一直在訊息產品開發一線耕耘，今年下半年轉入華為融合視訊業務。曾參與多個重要專案與重要版本的設計、重構與開發，輾轉多個語言：長期從事 C、C++ 開發，Java 與 Python 也有約 30K+ 程式碼的開發經驗，目前正在基於 Go 語言開發，對 HTML/JS/Shell 等指令碼語言也有一定掌握。

本文主要分析 C、C++98、C++11、Java 與 Go，主要論述語言的關鍵能力。在論述的過程中會結合華為各語言程式設計專家和華為電信軟體內部的骨幹開發人員的交流，摒棄語言偏好或者語言教派之爭，儘量以客觀公正的角度來論述下各個語言的特點和不足，對語言選型作為一個客觀的參考。

把這些寫出來，期望得到大家的指正與反饋，讓整個分析更客觀，效能方面，著重對 Go 做深入剖析參考。內容很多，期望不會讓你望而卻步。

語言整體概要

1、Go

在併發方面， goroutine 和 channel 機制提供了語言層面的輕量級和毫無拖泥帶水的併發機制；在效能方面，提供了不弱於 Java 的效能（效能是個偽命題），而記憶體資源消耗方面，相對 Java 和其它動態語言，具備明顯的優勢；在語法方面，具備了部分 Python 的動態語言特性，在物件初始化、構造和序列化等方面提供了無比簡潔的表述方式，而這些處理程式碼可能佔據 10%~50% 的程式碼分量，尤其對於處理資料、配置和協議對映場景，相比 C、C++、Java 在此方面拙笨，這就是動態語言為何讓人著迷的關鍵所在。

這也是為啥 Go 語言第一個版本釋出時就如此受人矚目的關鍵所在，尤其是對於動態語言來說，它提供了動態語言所不具有的併發與效能優勢，Pike 設計 Go 語言目的是想作為 C/C++ 的另外一個可選的角色（注意不是替換，其設計目標不是替換），Go 語言之父 Google 首席軟體工程師 Pike 2012 年“大道至簡”演講稿中對於此目標充滿沮喪，引用其中一句話：“Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.” 

C++ 的價值精髓在於：語言提供更加廣泛的抽象、優雅和靈活的特性，而這些表達能力是硬體零成本的，而 C 語言一開始就把硬體零成本作為其設計目的，但語言表述力是 C++ 來解決，Go 思考的方向顯然不是零成本，至少不是零 CPU 成本，Go 的主張更多考慮的是最小化程式設計師的工作量。

一個是硬體零成本的極致追求，一個是最小化程式設計師的工作量，誰都替換不了誰最有價值的部分，Go 無法同時符合兩個目標，它選擇了動態語法和 gc，就註定了它選擇開發效率，會為開發效率犧牲硬體效率，所以它走向另外一個方向，也就是 Java 所擅長的應用方向，尤其是目前的網路和 HTPP 應用方面，這就需要有良好的標準庫和生態系統支援，而在標準庫方面，Go 已提供了處理 tcp/http/xml/json/ 加解密等更輕量級和優秀的程式碼庫，對網路的核心協議 http 的高併發支援，已經為它提供了撬動 Java 的敲門磚。

但是我們必須面對它目前的不足，在其語言重要特性和嚴謹性方面還遠未成熟，還有不少斷層或臨時解決方案，而這也會影響到其生態的成熟度，這些問題還需要在新版本中解決。Go 語言 2012 年 3 月 28 日正式釋出第一個版本，截止目前 1.7 版本釋出，差不多一年兩個大版本釋出，中間還有數個 beta 與 RC 版本釋出，這也基本能說明 Go 語言還未完全準備好。

小結

Go 已經證明在動態語言需要效能方面，是作為 Python 和 Ruby 的理想候選者；在應用開發方面，尤其是 HTTP 相關應用方面，目前已經是站在 Java 面前的一位挑戰者，同時在對資源的掌控力不是那麼強烈訴求的地方也是 C/C++ 之外提供另外一種角色。

在生產力方面，其語言特性和生態系統還未成熟，版本還在快速迭代中，相比動態語言和 Java，並不具有優勢，目前階段是這些語言在某些場景下的可選角色。長期看，在 Google 的鼎力支援下，新特性和庫的應用能力還會不斷加入，是一門欣欣向榮的程式語言，但目前階段，建議必須控制好程式的規模和複雜度，語言和生態還未提供健全的支撐，同時還必須留意它的不成熟和版本快速迭代帶來的風險。

2、Java

Java 的成功得益於 10 年前以 Unix 系統為主的 SUN、IBM、Oracle 等大型公司的強力支援，這讓它在企業應用領域和 WEB 應用方面站穩了腳跟，而隨後的 10 年，前半段是靠 x86+Linux 帶來的革命繼續保持份額，後半段就是 android 的成功讓其在步履蹣跚停止腳步後再一次登頂。這二十年，Java 積累了最強大的生態系統，你可以說它無所不包， 毋庸置疑，Java 早已是一艘航空母艦的巨大身軀，這足已證明它的地位與成功。但是其語言、庫、框架和生態系統的複雜度，對技術人員構築其巨大的障礙，比如併發方面，語言的 synchronized 機制，標準庫的 notify 再到 concurrent，也可以通過 Apache+tomcat 容器來獲得 HTTP 等的並，而基於 JVM 技術，Java 又與其它語言具有良好的互操作性，比如併發方面的 Scala，可以選擇其 Actor 或者也是用 Scala 寫的 Akka，當然業界選擇 nginx 等混搭的場景更多，太多太多…

這就是 Java 的世界，永遠不嫌多，無需要重複造車馬，這是 Java 成功的關鍵所在，歷史沉澱下來的，讓 Java 提供的選項太多，深入後就知道 Java 的學習成本比 C++ 更高，對程式設計師的要求比 C++ 更高，除非掉隊了，還在用 7 年甚至 10 年前的 Java 技術，技術人員要非常精心地組織框架和設計，否則各種複用的結果就是堆砌出一個異常臃腫的程式，其執行時對資源的消耗有時候會讓你感到恐懼，而這是太多的基於 Java 所開發的平臺被廣泛詬病的關鍵所在，重用是個雙刃劍，需要量體裁衣而不是一鍋端，拿捏的尺度對開發人員要求無疑是最高昂的，除非語言和標準庫提供了最好最直接的選項。

小結

Java 早已證明它的無所不包，近十年基本都是排名最好的語言，積累最強大的生態系統。要澄清下一個誤區：如今 Java 的學習成本和對開發人員的技能要求，已經遠高於 C/C++ 的，也許大多數的開發人員無法駕馭 Java 這艘航空母艦。若要長期使用 Java，務必跟上 Java 的最新技術，同時在重用方面一定要拿捏好尺度，這會對人員技能提出更高要求，否則及其容易寫出資源佔用和執行時效率讓人感到恐懼的應用。

3、C、C++98、C++11……

C/C++ 在嵌入式和系統級程式設計方面，依然佔據著牢固的位置，因為諸如 Java 和 Go 等語言的關鍵發力點顯然在開發效率這一側，參考前面 Go 一章節的論述。

但是在併發、網路和應用程式設計等方面，一直處於諱莫如深的黑暗時代，語言本身未提供任何支援，而太單薄的標準庫也毫無此方面的野心，C/C++ 的標準庫的規模恐怕始終無法比擬 Java 與 Go，因為 C/C++ 不受任何一家大型商業公司控制而完全是“放養”狀態，標準庫需要得到大型商業公司持續的投資，這就是為啥 C++98 的標準庫在 13 年後才獲得一次大的更新。這直接導致 C/C++ 必須封裝各種硬體平臺的系統 API，而在 linux+x86 大面積擊敗 Unix 之前，眾多的 Unix 系統更加劇了跨平臺程式設計的難度，2000 年前出現一個很糟糕的跨平臺的 ACE，還有 windows 平臺上充斥大量巨集靜態全域性變數的同樣糟糕的 MFC 庫，這些都曾經被程式設計師當成救命稻草，這些技術顯然很快都被歷史丟棄，這下可以知道為啥如此多的人對 C/C++ 諱莫如深感到恐懼。而此時 Java 提供了多執行緒、網路和應用開發方面的標準庫和基於 JVM 技術的跨平臺支援，把 Java 推向主流程式語言，也就是 Java 前十年成功的關鍵所在。

對於 C/C++ 程式設計師，有一個振奮人心的大事件，C++11 釋出，相比 C++98，無論在語言和標準庫上，都是一個極大飛躍，C++ 之父說它是一門新語言，這不為過，同時如此多的頂尖 C++ 高手對 boost 庫的貢獻（其實已是實時上的標準庫），在網路、併發程式設計和一些基本應用方面，已經提供了效能最優秀的庫，極大地降低了此方面的開發難度。傳統的 C++ 程式設計師，儘快過渡到 C++11 上，這需要編譯環境的更新，而編譯環境更新又會帶來記憶體檢測和效能分析方面最強力的工具，C\C++ 曾經最廣受詬病的記憶體越界與洩露問題，在 gcc5.2 版本和 Intel 最新 CPU 面前，記憶體飛踩可以被抓在第一現場，同時Intel提供的 vtune 效能分析工具，是個人目前為止所遇到的最強大工具。

小結

傳統的 C++ 程式設計師，儘快過渡到 C++11 上，擁抱新的標準庫和 boost，這會極大提高在嵌入式和系統級程式設計方面的開發與維護效率。要擁抱全新語言，而語言的重大升級，廣義上看也是一門新語言，也要放到同樣重要位置，更好地發揮已有資產的產效。而在應用開發方面，由於標準庫方面就不要指望它可以匹敵目前階段的 Go，更不要說 Java，所以老老實實做好它最擅長的領域。

語言特性

1、併發

Go 在輕量級和簡潔方面具備最大優勢：goroutine 和 channel 機制提供語言層面的輕量級和毫無拖泥帶水的併發機制，標準庫也提供了基於此的應用庫；

在併發世界的混合程式設計方面，Java 提供了最多的選擇項和生態支援：十年前 java.util.concurrent 釋出後就已經把 Java 推向了併發程式設計高峰，在雲化下，Java 與 Scala 等高併發框架和語言具有良好互操作性；

C++11 相對於 C/C++98，向前邁出了一大步，標準庫和擴充套件庫 boost 庫已提供了優秀的跨平臺封裝，告別對作業系統 API 的維護，如同 10 年前 Java 的 concurrent 包釋出一樣，極大降低了此語言在併發程式設計方面的跨平臺的心智負擔，但線上程排程和管理方面，還是需要自己精心維護；

而對於 C/C++98 來說，僅華為電信軟體，有依賴 SNE/ENIP、有依賴 ACE、有風格各異的自行跨平臺封裝，尤其是 10 年前要支援 windows、linux、solaris、aix 等平臺，併發程式設計的黑暗時代，C/C++ 的開發難度也多半因為其併發和網路程式設計，語言和庫未提供支撐，必須白手起家。

小結

開發難度 Go < Java < C++11 < C/C98，學習曲線 Go < C++11 < Java < C/C98。可能有人會疑惑為啥 Java 比 C++11 的併發還難學，是因為 Java 提供的選擇項太多，語言、標準庫和其它語言框架互操作方面，要掌握和拿捏好，學習成本非常高昂，否則寫出來的程式可能非常低效或者不健壯或者複雜。

2、面向物件

Java、C++、Python 均提供了良好的面向物件的語言支援，配合設計模式、型別系統和工具鏈的支援等，Java 和 C++ 具備構建大規模程式所具備的基本要素；Go 語言雖然號稱支援面向物件，但它是通過方法與 interface 等間接模擬，無法直接清晰地組織物件結構並初始化銷燬它們，與 C 一樣，會充斥大量的全域性物件和結構體，管理物件的成本比較高，在構建大規模程式方面，語言能力還比較弱，還需要新的語言特性加入。

3、物理結構組織

物理結構的組織，對於中大規模的程式來說，相比類介面等邏輯結構的表述，具有更至關重要的作用，比如100萬行左右的C++程式碼，如果結構組織不好，影響是戰略層面的（邏輯結構組織對於大規模程式影響是戰術層面）：一行程式碼變更，編譯連結時間可能都是10分鐘以上，甚至數小時，僅僅編譯和重啟耗費的時間可能已擊垮整個開發效率。

包：在程式碼組織方面，包的作用無需要在闡述，Java 與 Go 基本上是天生就具備了此語言特性，而 C/C++ 顯然還不具備，C++ 只有比較弱的名字空間來避免名字衝突（更多的是邏輯結構組織），更多是通過目錄、標頭檔案/原始檔/HPP 檔案來組織程式碼分類，需要非常精心地處理和設計，否則引入迴圈和混亂依賴是家常便飯，對大規模程式的組織，對人員技能要求更高。

庫：在程式執行方面，Java 支援 jar 包的動態載入，具備良好地擴充套件和升級能力，而 C/C++ 支援靜態和動態兩種連結方式，但在載入方式方面，基本沒有控制力，未能如 Java 般靈活，Go 編譯後 linux 下基本只依賴 libc 庫，不支援動態連結，只支援靜態連結，最終編譯出一個相容 gdb 格式的執行程式，在部署方面具有極簡配置，但必須控制程式規模，否則在作業域可能會帶來聯動升級。

小結

Java 在此方面是最優的，而 C++ 必須要謹慎處理，Go 介於兩者之間。

4、型別系統和泛型

Java/C++ 均支援強型別的編譯時檢測，提供了編譯時的型別安全，便於發現低階的型別錯誤，同時支援泛型，便於表述通用的演算法和容器；Go 語言支援 Python 的動態語法，在處理型別申明定義方面程式碼更簡潔，但型別方面稍弱，目前階段還不支援泛型，這為表述通用的演算法和容器方面帶來了極大障礙和型別不安全，需要通過 interface {} 來模擬，如同 C 語言世界的 void *，或者 10 年前沒有泛型的 Java，其物件都繼承自 Object，當然 interface {} 不只是物件或資料結構型別，Java 的歷史已經證明此路不通，遲早會走到泛型，所以 Go 語言只是目前階段不支援而已，長期看應該是支援的，其發明者也說過，目前還未找到好的支援辦法。

小結

Go 還需要語言層面的新特性加入，相信這也是遲早的，在泛型方面，目前這幾門語言中，C++11 是做得最好的，Java 次之，而 C++98 在處理泛型型別方面常常會遇到晦澀和極難處理的語法錯誤。

5、初始化

初始化對於程式的健壯性、靈活性和可讀性，是至關重要一環，程式無法在各種複雜場景下良好地對變數賦值，其結果可想而知。

Java 做得比較好，有良好的 gc，面向物件，不支援全域性變數，資料成員支援分階段的初始化，未顯示賦值也有明確含義的初值，而類載入過程中也可以控制類、jar 包之間的複雜依賴關係。

C 在初始化方面的語言支援是最原始的，貶義點來說就是“最糟糕的”，不支援面向物件，全域性變數、自由函式和沒有明確含義的初值帶來了大量程序問題。

C++ 支援得比較好，面向物件，這幾門語言中唯一支援物件的析構和 RAII，在複雜物件和物件協作之間的初始化管理方面具有最強控制力，而 C++11 引入了 auto 與 decltype 等偏動態點的特性，讓 C++ 表現得更好；但是同時相容 C 語言的糟糕初始化，如果像 C 一樣用 C++，結果與 C 語言一樣，而這可能很普遍，這也是 C++ 被詬病的地方，這是繼承 C 語言資產帶來的其中一個負面，可以做得很好，也可能做得非常非常糟糕。

Go 在初始化方面，Go 借鑑了 Python 部分動態語言，在變數、陣列、struct、list 和 map 等結構方面，相信看過的都會為其簡潔點個贊。但目前還需要更多的版本催熟：gc 相比 1.5 之前版本已經有較大提升，目前還不支援構造和析構，而 defer 一定程度上模擬了，但相比 C++ 的 RAII 和 Java 的物件、finally 等機制，還不成熟，很容易引入諸如效能和資源洩漏方面的缺陷；初始化不統一， New、make、{}等各種特定領域的初始化方式，這也是暴露 Go 的語言設計方面還不成熟的一方面，要知道 Java 與 C++、C 只需要一個 new 或者 malloc。

6、錯誤處理

錯誤處理對於複雜邏輯的組織和程式的健壯性，是至關重要的，比如一個簡單的讀檔案，C 語言處理需要開啟檔案，判斷開啟結果；讀取資料，判斷讀取資料結果；把資料對映為物件，判斷每個引數結果….，就知道錯誤處理是多麼地繁瑣。

健全的程式語言 Java/C++/Python/C# 等無疑都把異常處理放在第一優先位置。可惜 Go 目前還不支援，而是通過多值返回錯誤碼方式，或者 panic – recover 機制，讓錯誤處理程式碼充滿整個邏輯，相比 C 的錯誤返回，有時候可能更糟糕。

7、動態語法

為啥要把動態語法作為一個關鍵項呢，相信用過 Python 等的，不考慮其它執行效率因素，無疑會對其簡潔耳目一新，尤其是在物件初始化和構造方面，而這是程式程式碼中可能佔據 10% 甚至 50% 程式碼的地方，尤其對於處理資料、配置和分析的系統。

Go 借鑑了 Python 的部分動態語法，在反射的配合下，相比傳統的 JAVA、C++ 的拙笨，是一個大的提升，當然此方面還需要不斷提升，尤其字元串和型別相容方面，斷層還比較多，無疑在做資料處理方面，相對 Java、C++、C，Go 是更好的選擇。

8、其它重要語言特性

運算子過載對於可擴充套件的型別運算來說，無疑是最優雅的；函式過載對於增量維護開發和支援各種簡便呼叫來說，也是必不可少的；lambda 已經是健全的通用語言 C++11/Java/python/C# 的必選項，lambda 在資料的初始化和控制邏輯表述方面，無疑是一個利器…… Go 語言還不支援這些重要的語法特性，需要後續版本增強。

生態

1、標準庫

Java 的標準庫無疑是最成熟最強大的，提供了拿來即用的高可複用的類和庫，無需要重複造車馬，這是 Java 成功的關鍵所在，但 Java 發展至今，其語言、類庫和框架早已經是一艘航空母艦，且圍繞其 JVM 不斷有新技術新庫湧現，要掌握拿捏好的學習成本是最高昂的，許多 Java 程式設計師其實掉隊了，如同 C++ 一樣，可能還在使用 7 年前甚至 10 年前的 Java 技術，Java 應用領域，必須跟上新技術步伐，同時要非常精心地組織框架和設計，否則各種複用的結果就是堆砌出一個異常臃腫的程式，其執行時對資源的消耗有時候會讓你感到恐懼，而這是一些平臺被廣泛詬病的關鍵所在，重用是個雙刃劍，需要量體裁衣而不是一鍋端，拿捏的尺度對開發人員要求無疑是最高昂的。

Go 除了提供雷同 C++11 標準庫和 boost 庫的基礎能力，同時在應用庫方面，尤其是網路和 WEB 程式設計，提供了支援併發的優秀庫，如果對於 C++ 的應用能力薄弱和 java 的龐大感到恐懼，無疑 Go 是需要面對一個好的選擇。

C++11，併發程式設計等已經納入到標準庫，同時實時上的標準擴充套件庫 boost 無疑提供了基本的應用複用能力，C++11 在做跨平臺併發和網路應用程式設計方面，完全可替代傳統的 C/C++98，讓曾經的黑暗年代往前邁出一大步。但是在做 WEB、資料庫和資料分析等企業應用開發方面，C++11 的庫還是非常地單薄。

2、工具鏈

C/C++/Java 的工具鏈，就不用詳細敘述了，從編輯器、程式碼瀏覽跳轉、除錯、程式碼文件自動生成、複雜度度量、findbug、記憶體排查、效能監控等已經非常鑑權，華為的 CI 環境也提供該了良好支援，就不詳細敘述了。

重點審視 Go 語言，開發環境通常會選擇 Eclipse 或者 LiteIDE，選擇 Eclipse，麻煩就許多，由於 Great wall 的原因，不能直接獲取外掛：Go 工程需要 GoEclipse、程式碼跳轉需要 gocode、程式碼除錯需要裝 gdb，這些都單獨下載下來，健全點還需要安裝 guru 和 godef，有些需要做編譯，安裝 Eclipse 的 Go 的健全環境，看個人情況，差不多要 0.5~2 天就能工作了，所以推薦 LiteIDE，它的包裡基本都有，裝上差不多也能用了。但是這些環境只能簡單用，開發工作中會遇到許多重要體驗問題，如下：

• 編輯閱讀重要體驗欠缺

程式碼瀏覽：沒有程式碼的物件、函式、變數的全域性瀏覽和查詢功能，只能一個個檔案地開啟進去看，這對於大型工程，檔案多，檔案大，習慣了 Eclipse、source insight 和 .net，沒有瀏覽，會抓狂；程式碼搜尋和跳轉：不能列印名字，函式類介面等能夠自動羅列出來，而前後跳轉功能基本上也不能用，對於大型工程又是個重大體驗丟失； 其它重要體驗：無重構工具、無程式碼自動生成工具、編譯錯誤不能隨見隨得……

• 程式碼除錯重要體驗欠缺

Windows的除錯依賴 gdb，gdb 在 windows 環境不大可靠，所以不要期望它在 windows 環境能夠如期工作良好，除錯就最好到 linux 環境下，或者寫 print 列印到控制檯，習慣 Windows 環境滋養的，恐怕又要適應下新的非圖形化環境。

• 動靜態檢測工具欠缺

缺乏圈複雜度、codex 套件安全檢查（可以直接呼叫 C/C++ 的程式碼）、記憶體檢查（可直接使用指標和呼叫 C 程式碼）。

小結

基本能用，但是一些提高效率的重要體驗喪失，目前階段如果給 Java/C++ 的開發環境打 5 分，Go 的環境，目前只能給 2 分，且 Go 一年差不多 2 個大版本，對開發環境也是個重要的挑戰（Java/C++ 甚至用 5 年甚至 10 年前的環境），公司要做的工作還非常多，且要管控其版本快速迭代帶來的切換衝擊。Google 公司在還未成熟就早早開源的目的之一就是期望業界能夠提供更多工具，而工具基本都是開源世界貢獻，而 Android 基於 Java 開發，所以 Google 能直接拿來用，而 Go 作為一門全新語言，在開發環境方面，Go 目前還未及格。

3、語言流行度和開源專案分析

說到語言，必然會想到 TIOBE、PYPL 和 GitHub 的排名，我們看看它們的資料：

• TIOBE 資料

語言的熱度必然得看權威的 TIOBE 世界語言排名， 2016 年 6 月最新資料排行榜：

新語言 Go 的最新排名是 48 位，與 Java 的熱度差距是 100 倍。2 年前的 2014 年 7 月，Go 語言排名 30 位，指數是 0.222%，2015 年 7 月 Go 未排入前 50，2016 年最近 5 月排名分別是：50+、38、48、44 和 42。

近三十年語言熱度排行榜：

•  PYPL 的最新資料

• GITHUB 的資料

開源社群，挑選最具代表的 github 上的開源語言排名：

點評

主流程式語言始終具有強大的生命力，Java、C、C++、C#、Python、JavaScript、PHP 從近十年資料看，都未離開過前十名，其它語言扮演的是在某些情況下的一種可選角色，注意不是替代這些主流語言，因為目前還未見它們衰落的跡象。

Java 近十年始終是王者；C/C++ 地位也始終穩固，在嵌入式、系統級程式設計方面始終佔據統治地位，在動態語言方面；Python 的簡潔和生態讓它佔據著膠水語言的角色，當然也有用它來寫不那麼苛求效能的服務端程式；而網站，PHP 和 JS 就不用多說了，70% 的網站依然是用 PHP 寫的。

Go 2009 年正式版本離釋出還有兩年就掀起了一陣子熱潮，正如 Go 語言的之父所說，創造了另外一種角色，在 Python/Ruby 需要效能時的一種可選角色；而相對於 Java，它創造了更輕量級更高效率的一種角色，為撬動史前巨獸 Java 提供了敲門磚，但是語言、標準庫和工具鏈的成熟度牽扯到關鍵的生產力，這方面它還未準備，而在效能方面，作為新語言，它的排程器也未準備好，還有諸多效能陷阱，看另外一篇文章單獨論述。

4、行業應用

對於 Java、C、C++，前面已有說明，在生產力方面，Java 已經無所不包的航空母艦了，而在苛求效能方面，C/C++ 依然佔據著牢固的地位。對於 Go，的確已經證明了它在需要效能時是 Python 與 Ruby 這些指令碼語言的一個選項，而這些動態語言指令碼基本應用在管理域：環境資源應用的監控和部署等，也有些把它們拿來做服務端開發，而在苛求效能時，這些語言的確就不擅長了；在 Java/C/C++ 所擅長的領域，成功的應用太多太多，Go 在某些場景下，比如資料分析或 HTTP 應用方面，它是一種可選的角色，而在通用和複雜應用業務域，無論語言、生態和成熟度，都未準備好。Go 要做的工作還很多，還需要更多地迭代。

其它業界主流語言簡要

Python/JavaScript/C# 近十年，也是最流行的語言之一，與 Java/C/C++/PHP 語言一樣在各自領域獨領風騷，而這些語言在部門也或多或少有應用，但由於非業務模組，重視度沒那麼高，其實頁面、工具和管理域，涉及到重要體驗問題，還是需要引起足夠重視，否則積累的程式碼多了，可維護性和體驗都會帶來越來越大的負擔。

1、Shell/Python

歷史遺產及其慣性，安裝、部署、升級和監視管理任務等方面，基本還在使用 c shell 或 b shell 指令碼，shell 的語法深晦，可讀性極差，同時編輯調試環境都是最原始的，開發和維護效率基本都是最低的，而這些非業務部件，平時都是三不管的，積累的程式碼也不少，要專人熟悉 shell 的維護。而 Python 在處理字串、容器和環境方面，是本文所列的語言中，最簡潔生產力最高的語言。

建議作業域的指令碼儘量用 Python，在管理域，膠水語言的名號無出其右，而 Python 基本也是排行榜前五的語言。

2、JavaScript/Typescript

JavaScript 可以說是最流行的網頁尾本語言了，但它的設計有兩個一直被詬病的缺陷，一是太簡單；二是弱型別，語法錯誤到執行時才會發現，應該沒人沒遇到過網頁不知為啥跳出一個警告框的情況吧。當 JS 程式碼超過萬行時，它的簡單語法和弱型別會給維護人員帶來巨大的負擔，個人只寫過幾百行的 JS 頁面，對弱型別基本無法忍受，以前也下載過新浪這樣的複雜入口網站看 JS 程式碼，說實話，深入不下去，直接放棄。Typescript 出現，剛好是為了解決 JavaScript 這兩個設計缺陷。

對於 Typescript，或許習慣 JavaScript 會拒絕它的面向物件等增強表達力的語言特性，覺得是讓簡單變複雜。但另外一個特性，也就是免費為 JavaScript 增加編譯時的型別檢查，相信沒有人會拒絕這樣的特性，就跟寫文章指出錯誤的做法。所以寫 JS 頁面的，還是切換到 TS 這個超集。

3、C#

C# 在華為就更小眾了，但它也是最流行的語言之一，而真真能挑戰 Java 地位就是 C#，可惜微軟把它禁錮在 windows 系統，也限制了世界最頂尖的語言和編譯器專家丹麥人 Anders Hejlsberg 的影響力，C# 目前正在逐步走向開源，同時它依附於目前最強大的整合環境 .net 也在走向開源。