看到這個問題的時候，我瞬間有些恍惚，有哪些地方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 meoney!
相比較而言，可能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則更加流行。
一個新貴藺相如，一個老廉頗，他們能將相和嗎？
我是明月，
一個網際網路說書人!