看到這個問題的時候，我瞬間有些恍惚，有哪些地方Go能做到？.NET會不做到，C#不行呢？
那我們就掰開了揉碎了，從Go可能勝出的地方，來挨個分析一下：
1、交叉編譯
在Windows平台上面編譯Linux和Mac平台的程式，Go可以，C#應該也可以，透過publish機制一樣辦得到！
2、物件導向
這個應該討論的是「Go能否達到.NET那樣的水平？」
雖然Go的interface和struct可以做到「實作和宣告」分離，但是C#的interface一樣可以，不過沒有Go分離的那麼徹底，這應該是C#的一個「弱點」。
但同時，C#嚴格的Interface/Implement機制，也保證了大型專案的安全性，不會出現有些Go程式裡面interface滿天飛的情況！
另外一點，個人覺得C#的Class機制更加符合我的程式設計思維。很多老一點的程式設計師，其實都遵循相同的程式設計軌跡，C到C++，然後Java，可謂一直是Class護體。
寫了這麼多年的Class，即便是用go，那也是class的靈魂。
不怕各位笑話，我一般都是定義一個struct，然後就開始定義方法，像這樣：
type Person {
Name string
Age int
}
//下面開始進入C++型態
func (p Person) CalSome(){
}
func (p *Person) IncSome(){
}
//開始呼叫
p := Person{
Name:"ttt",
age:45
}
p.IncSome()
仔細想來，這和C#的差別到底有多大，個人覺得，區別不大！
從程式的「美感」來講，其實C#更美！
3、反編譯
如果說以前，確實Go在Windows平台上面，編譯為一個Exe檔案以後，想反編譯出Go的原始碼，那幾乎是不可能的。
C#這邊非常容易。如果你知道這是一段.NET程式碼，想反編譯的話有很多工具可以使用，包括ILDASM、dotPeek、ILSPY。
當然Java這邊也有jd等反編譯工具。
現在.NET提供了AOT選項之後，其反編譯功能應該有很大的進步。AOT編譯處理的程式碼都是本機程式碼，再想反編譯就和Go一個難度了。
分久必合，合久必分，語言期間其實也是各種功能互相「借鑑」。
4、Docker映像大小
這個應該是Go勝出的一個領域。
使用Alpine作為Base Image，前幾天我做了一個映像，docker images顯示其大小為13M。
如果使用「scratch」映像作為Base，相信會更小。
而.NET的AspNetCore則顯然大很多，30M+。
如果說需要很多個Docker Image運行在k8s裡面，無疑Go映像的佔用會低很多。
5、Father
最後，那就只好比一比老爸了，畢竟富二代出生在羅馬，而普通人的人生目標就是羅馬！
Go的father是Google。
.NET的Father是微軟！
一個是有點舊的「新時代霸主」，一個是有點「舊貌換新顏」的Old Money！
相比較而言，可能Google要強勢一些。
從這點出發，Go略勝，.NET略敗！
當然，Father的影響也很大，.NET從誕生之初就不太受人待見，受到Java的打壓。
這一點，好像在我們熊貓國還特別突出。
現在熊貓國的大公司，騰訊已經在把主力語言從C/C++全面轉向Go語言；字節跳動則是Go預設是程式語言第一選擇，沒有特殊需求，一般都是使用Go來開發，Rust尚且排在Go後面；七牛的許志偉則一直就是Go的狂熱擁護者，甚至開發了一門Go+語言，相當於Go的改進版本。
目前看來，除了阿里堅守Java陣營，Go在中國大公司裡面已經非常流行。相比較而言，.NET則生意慘淡，在工業控制、MES、物聯網、HIS等領域艱難求生，薪水也不容樂觀。
在熊貓國，從人氣這一方面，Go無疑完勝.NET。
總結
從語法、功能角度來講，Go能做到的，.NET也能做到，甚至更好。
從體積來講，Go可以更輕量級，畢竟.NET已經是多年的積累，積重難返！
從人氣來講，特別是網際網路領域，Go的使用率完勝.NET；而在工廠等非網際網路領域，.NET則更加流行。
一個新貴藺相如，一個老廉頗，他們能將相和嗎？
我是明月，
一個網際網路說書人！