golang是壹編譯型的強類型語言，它在開發上的高效率主要來自於後發優勢，不用考慮舊有惡心的歷史，又有壹個較高的工程視角。良好的避免了程序員因為“ { 需不需要獨占壹行 ”這種革命問題打架，也解決了壹部分趁編譯時間找產品妹妹搭訕的階級敵人。
它有自己的包管理機制，工具鏈成熟，從開發、調試到發布都很簡單方便；
有反向接口、defer、coroutine等大量的syntactic sugar；
編譯速度快，因為是強類型語言又有gc，只要通過編譯，非業務毛病就很少了；
它在語法級別上支持了goroutine，這是大家說到最多的內容，這裏重點提壹下。首先，coroutine並不稀罕，語言並不能超越硬件、操作系統實現神乎其神的功能。golang可以做到事情，其他語言也可以做到，譬如c++，在boost庫裏面自己就有的coroutine實現（當然用起來跟其他boost庫壹樣惡心）。golang做的事情，是把這壹套東西的使用過程簡化了，並且提供了壹套channel的通信模式，使得程序員可以忽略諸如死鎖等問題。
goroutine的目的是描述並發編程模型。並發與並行不同，它並不需要多核的硬件支持，它不是壹種物理運行狀態，而是壹種程序邏輯流程。它的主要目的不是利用多核提高運行效率，而是提供壹種更容易理解、不容易出錯的語言來描述問題。
實際上golang默認就是運行在單OS進程上面的，通過指定環境變量GOMAXPROCS才能轉身跑在多OS進程上面。有人提到了網易的pomelo，開源本來是壹件很不錯的事情，但是基於自己對callback hell的偏見，我壹直持有這種態度：敢用nodejs寫大規模遊戲服務器的人，都是真正的勇士 : ) 。
2、Erlang與Golang的coroutine有啥區別，coroutine是啥？
coroutine本質上是語言開發者自己實現的、處於user space內的線程，無論是erlang、還是golang都是這樣。需要解決沒有時鐘中斷；碰著阻塞式i\o，整個進程都會被操作系統主動掛起；需要自己擁有調度控制能力（放在並行環境下面還是挺麻煩的壹件事）等等問題。那為啥要廢老大的勁自己做壹套線程放user space裏面呢？
並發是服務器語言必須要解決的問題；
system space的進程還有線程調度都太慢了、占用的空間也太大了。
把線程放到user space的可以避免了陷入system call進行上下文切換以及高速緩沖更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語言反復提及的超高並發能力，分分鐘給妳開上幾千個線程不費力。
不同的是，golang的並發調度在i/o等易發阻塞的時候才會發生，壹般是內封在庫函數內；erlang則更誇張，對每個coroutine維持壹個計數器，常用語句都會導致這個計數器進行reduction，壹旦到點，立即切換調度函數。
中斷介入程度的不同，導致erlang看上去擁有了preemptive scheduling的能力，而golang則是cooperative shceduling的。golang壹旦寫出純計算死循環，進程內所有會話必死無疑；要有大計算量少i\o的函數還得自己主動叫runtime.Sched()來進行調度切換。
3、golang的運行效率怎麽樣？
我是相當反感所謂的ping\pong式benchmark，運行效率需要放到具體的工作環境下面考慮。
首先，它再快也是快不過c的，畢竟底下做了那麽多工作，又有調度，又有gc什麽的。那為什麽在那些benchmark裏面，golang、nodejs、erlang的響應效率看上去那麽優秀呢，響應快，並發強？並發能力強的原因上面已經提到了，響應快是因為大量非阻塞式i\o操作出現的原因。這壹點c也可以做到，並且能力更強，但是得多寫不少優質代碼。
然後，針對遊戲服務器這種高實時性的運行環境，GC所造成的跳幀問題確實比較麻煩，前面的大神 @達達 有比較詳細的論述和緩解方案，就不累述了 。隨著golang的持續開發，相信應該會有非常大的改進。壹是屏蔽內存操作是現代語言的大勢所趨，它肯定是需要被實現的；二是GC算法已經相當的成熟，效率勉勉強強過得去；三是可以通過incremental的操作來均攤cpu消耗。
用這壹點點效率損失換取壹個更高的生產能力是不是值得呢？我覺得是值得的，硬件已經很便宜了，人生苦短，讓自己的生活更輕松壹點吧: )。
4、基於以上的論述，我認為采用go進行小範圍的MMORPG開發是可行的。