golang支持跨平台嗎,go語言怎麼實現跨平台

本文目錄一覽：

• 1、使用Go 語言開發大型 MMORPG 遊戲伺服器怎麼樣
• 2、Go語言的支持平台
• 3、寫小程序，什麼語言跨平台兼容和性能較好？golang
• 4、學習go語言，用什麼IDE比較好
• 5、Golang項目部署3，容器部署

使用Go 語言開發大型 MMORPG 遊戲伺服器怎麼樣

從2013年起,經朋友推薦開始用Golang編寫遊戲登陸伺服器, 配合C++做第三方平台驗證. 到編寫獨立工具導表工具GitHub – davyxu/tabtoy: 跨平台的高性能便捷電子表格導出器. 以及網路庫GitHub – davyxu/cellnet: 簡單,方便,高效的Go語言的遊戲伺服器底層. 最終使用這些工具及庫編寫整個遊戲伺服器框架, 我的感受是很不錯的

細節看來, 有如下的幾個點:

語言, 庫

Golang語言特性和C很像, 簡單, 一張A4紙就能寫完所有特性. 你想想看, C++到了領悟階段, 也只用那幾個簡單特性, 剩下的都是一大堆解決各種內存問題的技巧. 而Golang一開始就簡單, 何必浪費生命去研究那一大堆的奇技淫巧呢?

Golang的坑只有2個:1. interface{}和nil配合使用, 2. for循環時, 將循環變數引入閉包(Golang, Lua, C#閉包變數捕獲差異) 完全不影響正常使用, 複合語言概念, 只是看官方後面怎麼有效的避免

用Golang就忘記繼承那套東西, 用組合+介面

用Golang伺服器如何保證解決遊戲伺服器存檔一致性問題? stop the world是肯定的, 但是Golang可以從語言層並發序列化玩家數據, 再通過後台存檔

channel是goroutine雖然是Golang的語言特性. 但是在編寫伺服器時, 其實只有底層用的比較多.

Golang的第三方庫簡直多如牛毛, 好的也很多

不要說模板了, C#的也不好用, 官方在糾結也不要加, 使用中, 沒模板確實有點不方便. 用interface{}/反射做泛型對於Golang這種強類型語言來說,還是有點打臉

運行期

Golang和C++比性能的話, 這是C++的優勢, Golang因為沒虛擬機, 只有薄薄的一層調度層. 因此性能是非常高的, 用一點性能犧牲換開發效率, 妥妥的

1.6版後的GC優化的已經很好了, 如果你不是高性能,高並發Web應用, 非要找出一堆的優化技巧的話. 只用Golang寫點遊戲伺服器, 那點GC損耗可以忽略不計

和其他現代語言一樣, 崩潰捕捉是標配功能, 我用Golang的伺服器線上跑, 基本沒碰到過崩潰情況

熱更新: 官方已經有plugin系統的提交, 跨平台的. 估計很快就可以告別手動cgo做so熱更新

開發, 調試, 部署, 優化

LiteIDE是我首選的Golang的IDE, 雖然有童鞋說B格不高. 但這估計實在是找不到缺點說了, 別跟我說Visual Studio, 那是宇宙級的…

曾經聽說有人不看好Golang, 我問為啥: 說這麼新的語言, 不好招人,後面打聽到他是個策劃… 好吧

真實情況是這樣的: Golang對於有點編程基礎的新人來說, 1周左右可以開始貢獻代碼. 老司機2~3天.

開發效率還是不錯的, 一般大的遊戲功能, 2*2人一周3~4個整完. 這換C++時代, 大概也就1~2個還寫不完. 對接伺服器sdk的話, 大概1天接個10多個沒問題

Golang自帶性能調優工具, 從內存, CPU, 阻塞點等幾個方面直接出圖進行分析, 非常直觀, 可以參考我博客幾年前的分析: 使用Golang進行性能分析(Profiling)

Golang支持交叉編譯, 跨平台部署, 什麼概念? linux是吧? 不問你什麼版本, 直接windows上編譯輸出一個elf, 甩到伺服器上開跑.不超過1分鐘時間..

Go語言的支持平台

LiteIDE是一款專門為Go語言開發的跨平台輕量級集成開發環境（IDE），由QT編寫。

LiteIDE主要特點： 支持主流操作系統

Windows

Linux

MacOS X Go編譯環境管理和切換

管理和切換多個Go編譯環境

支持Go語言交叉編譯 與Go標準一致的項目管理方式

基於GOPATH的包瀏覽器

基於GOPATH的編譯系統

基於GOPATH的Api文檔檢索 Go語言的編輯支持

類瀏覽器和大綱顯示

Gocode(代碼自動完成工具)的完美支持

Go語言文檔查看和Api快速檢索

代碼表達式信息顯示F1

源代碼定義跳轉支持F2

Gdb斷點和調試支持

gofmt自動格式化支持 其他特徵

支持多國語言界面顯示

完全插件體系結構

支持編輯器配色方案

基於Kate的語法顯示支持

基於全文的單詞自動完成

支持鍵盤快捷鍵綁定方案

Markdown文檔編輯支持

實時預覽和同步顯示

自定義CSS顯示

可導出HTML和PDF文檔

批量轉換/合併為HTML/PDF文檔 Sublime Text 2（以下簡稱Sublime）+ GoSublime + gocode + MarGo的組合。

其優點有： 自動化提示代碼。 保存的時候自動格式化代碼，讓您編寫的代碼更加美觀，符合Go的標準。 支持項目管理 支持語法高亮 熟悉Java的讀者應該對於idea不陌生，idea是通過一個插件來支持go語言的高亮語法，代碼提示和重構實現。

寫小程序，什麼語言跨平台兼容和性能較好？golang

我最早使用的語言是Java和Python， 並且一直都對Python充滿好感， 我喜歡這種很樸實和高效率的感覺， 但我卻最後沒有採用Python，原因其實也很簡單， 我就是不喜歡縮進語法， 就跟很多人換工作僅僅是為了屏幕更大一點一樣， 另外就是有了同樣很棒的可選方案， 這就是Ruby， 所以我最終採用了Ruby作為主力編程語言， 同樣也為不能使用Python而有一點小遺憾，畢竟Python的健壯性比Ruby好很多，只不過Ruby也一直在進步， 所以這一點無傷大雅

我們都知道，無論是Python還是Ruby，甚至Java， 都是在解決業務層的問題， 屬於應用型語言， 以解決業務邏輯為主， 但還有一個領域是系統領域，偏網路層和底層操作，在這一塊我一直在尋找一種優雅的方案， C++被我首先給淘汰掉了， C的開發效率太低， Java倒是比較合適， 就是太臃腫，而且缺少系統編程的基因，畢竟它是企業級開發出身的

最後我選擇了Erlang， 因為它在網路層方面表現優秀， 同時容錯性和健壯性都很不錯， 它的虛擬機是唯一可以跟JVM媲美的， 而且還有OTP的超重量級武器， 幾乎可以是通殺網路層應用， 但根據我的總結它有一個硬傷和一個軟肋，這一點後面展開，可以說選擇Erlang是我目前所知道的方案裡面是最優的

直到有一天我了解了Golang， 我知道Golang其實也蠻早的， 大概08年的時候就知道Google在搞一門奇怪的語言， 之後的幾年，一直有不少以老莫為代表的人在嘀咕Golang， 其實我一直沒太關注，我從ROR中吸取的經驗是，成熟度對於商用很重要， 後來基於Golang開發的產品越來越多，讓我不得不去研究一下， 這我才知道， 這就是我夢想中的Python， 效率和性能達到了最佳的平衡，對Go了解越多， 就越不願意用Erlang寫代碼，主要原因：

1、Erlang的硬傷在於代碼的可讀性、表現力， 讓我來舉個小例子， 比如你為你的系統軟體構建一個RESTFUL的介面，我們大致了解一下代碼風格，先不說Erlang， 無論是你c/c++/python/ruby/java 出身， 對Go是不是有種很久違的感覺, 為什麼說是硬傷？ 因為對一門語言來說，語法是不大可能會大幅度變更的， 而且不會出現大的變化， 我不知道有沒有人讀過《松本行弘的編程世界》，裡面闡述的道理很明白， 真正好的編程方式是人去主宰計算機而不是計算機主宰人， 我感覺Erlang就有點主宰我的編程思維的感覺(我的視力本身就不好，它還在不斷的扼殺我的眼睛！)， 編程首先是門邏輯學，其次是工程學，最後才是數學， 又讓我想起吳軍的《數學之美》所說的， 人工智慧上個世紀一直在走彎路， 期望機器的高度圖靈完備， 而忽視人類本身已有的文明，統計歸納的應用

2、Erlang的軟肋在於高質量的庫少，儘管有不少殺手級應用， 同樣Go在這方面也是軟肋， 這一點對於一個不到五年的語言有情可原， 但對於一個20多年的語言是不是有點說不過去， 比如你用json解析庫，很多人都是從mochiweb這個基本不更新的庫中去抽取， 而我認為對於類似json這種東西可以考慮融入到語言標準庫中， 因為未來的商業軟體的api化趨勢越來越明顯，說的難聽點 ， 一個倚老賣老一個與時俱進，反正我對Golang的庫一點也不擔心， 目前的成績易經非常棒了， 遠遠優於Ruby/Python的前五年， 可參見已有的高質量的庫列表

3、Erlang不合群， 這主要體現在跟其他語言的交互性上， 當然這也有深層次的原因， Erlang本身有自己的哲學， 如出錯恢復機制， 你融入一個其他語言的東西進去， 這帳就不好算，就好比你硬要讓一個喝咖啡的跟一個吃大蒜的坐在一起， 總之你寫一個Erlang的port遠遠比Go複雜， 甚至比Python/Java還要複雜， 這就造成了Erlang在底層編程上效果不是很好， 沒法利用linux已有的很多優秀成果，我一直認為Erlang的什麼的mysql/pg/oracle驅動都沒有必要存在， Erlang一定是一個self-container應用， 你只要用到了其他東西， 根據木桶理論， 你就不敢號稱9個9，以系統的眼光看問題， 我覺得一個系統的魯棒性不能依賴於某一組件， 這也是為什麼愛立信本身的Erlang應用並不廣泛

4、說說數據類型吧， 我不止聽到1個人說Erlang對字元串的處理不有好， 它把string當做list來處理，其實本質上是該這麼，但，還是那句話， 違背了面向人的哲學， 應該做一些DSL， 比如Golang裡面的 := 就是一個糖衣， 等價於 var xx yyy = zzzz， 大大方便的程序員少敲不少字元, Golang裡面對字元轉可以說基本和python差不多， slice map函數很強大， 支持lambda條件，雖然Erlang的基本類型很少， 但有很多構造， 所謂構造等價於Golang裡面複雜的struct， 也奇怪了，我就是感覺Erlang構造傷眼睛好嗎？可能是各種括弧的比對的原因吧， 而且我認為這是不必要的， 顯然Erlang缺少DSL的基因， 當然跟Erlang出身的年代有關， 我不誇張的說， 自打用Erlang以後我的視力又下降了100度左右， 我不是很喜歡lisp所說的符號也是一種語法， 可能這又跟函數式編程有關吧：形式推導遠大於邏輯演繹

5、其實我最不關注的是性能問題， 因為隨著摩爾定律， 單位計算單元的性價比會無限高，但Golang既然提出它的性能逼近C， 那我還是提一下吧， 當然， Erlang也還可以， 雖然比Java慢， 但跟Python一個檔次吧

6、再談談報錯機制， 因為Erlang的的報錯信息太讓人糾結了， 起初以為我不會看出錯信息， 後來也使用了Sasl， 還是不夠直觀，甚至有時要用工具分析crash文件來定位問題，還是跟Erlang的哲學有關， 在Erlang中一切都是並行的， 所以它根本不care是物理哪一行出錯， 只跟Actor綁定， 然後告訴你Actor的ID和出錯代號， 你自己憑經驗去分析吧，這樣做的好處是可以很方便定位出並行中出現的問題，但凡事都是相對的， 在這一點上有點糾枉過正，根據我的經驗， 絕大部分時候我只希望先給我明確的指出哪一行出錯了好嗎？ 甚至把順序的backtrace用完整的英文句子列印出來好嗎？至於並行中的錯誤及時在命令式多線程語言中是不常見的，雖然並不是沒有， 但遇到錯誤我再費勁去調試好了， 但並不是所有的邏輯都用並行的思維去定位問題， 我甚至認為， 對於一個系統不完全是並行也不完全是串列，跟好比我們衡量世界不能單純的唯物也不能完全的唯心一樣， 這一點Golang就做了很好的折中， 不需要並行的時候你老老實實的寫串列代碼， 需要並行的時候也有較複雜的機制來應對， 合乎情理

7、再說說招人吧， 以前招過好幾個C出來的人，說實話水平很好， 可以一周就完成一個小組件， libevent用的熟的很，後來我逼人家用Erlang，結果把人家逼走了，至今我還很後悔， 自己的一廂情願強加在別人身上真是太不合適了，但我招純Erlang出來的人，可以說比招objc的人還難， 沒有人，空談技術的優雅性首先就是不靠譜的，再看看郵件列表， Golang的活躍度明顯比Erlang高很多， 基本逼近Ruby，更重要的是， 我根本不擔心Golang的人才，因為只要熟悉Python/C/Ruby/或者C++， 基本可以實現半天入門， 之後就可以噼里啪啦邊搜資料邊幹活了，雖然有足夠的深度，但門檻極其平緩，工程人員也可以復用很多已有的知識。 Erlang在這一點其實跟第一點硬傷有關，大部分人學一周都摸不著頭腦，不是每個人的抽象思維和世界觀都是一樣的好嗎， 所以函數式編程儘管不比命令式語言起步晚，但始終學的人很少，這就是歷史， 對於大部分人， 更希望解決問題，創造價值， 而不是數學來推導去

8、最後我建議， 如果你是玩c/c++的， 現在開始學Golang，是最好的時機， 跟一門靠譜的語言一起成長， 這種感覺非常棒， 你用Erlang折騰1個應用， 用Go恐怕都完成了10個開源項目， 當然，也要結合自己的口味， Golang就是Sublime Text， Erlang就是Emacs

相信自己的判斷，相信自己的邏輯， 贏就是贏，輸就是輸

轉載僅供參考，版權屬於原作者。祝你愉快，滿意請採納哦

學習go語言，用什麼IDE比較好

1、Sublime text

這個文本編輯器在編程界極為普遍，它並非一個完全成熟的IDE，但它具備了很多語言的擴展插件，比如Pyhon、lua等，其中有一個插件GoSublime專門針對Go語言，提供了語法高亮、自動補全等功能，這些功能使Sublime Text稱為一個很實用的Go IDE。

2、IntelliJ

由Jetbrains提供，在Java開發者中更為流行，其自帶的Go插件支持語法高亮顯示、代碼補全、自動編譯以及子庫支持，這就使使用者可以很方便地將項目拆分成多個包，可以在一個單獨的IDE中瀏覽它。它有個很好用的功能，插件使用了突出顯示來顯示未使用的變數或包。

3、LiteIDE

目前也是一個專門針對Go的IDE了，功能很全面，具備語法高亮、自動補全、自動編譯、調試、包瀏覽及管理。調試器在後台使用的gdb，這樣可以方便地列印變數值、查看當前堆棧信息。

4、Intype

是僅Windows下支持的文本編輯器，具備有限的語法高亮支持和特定的高亮顯示設置。

5、Netbeans

Netbeans內建支持了大量語言，同時具備Go插件，從而可以同創建正常項目一樣，創建Go源文件，除了語法高亮以外，其Go插件並不支持其他特殊功能，如何使用IDE編譯Go文件還不得而知。

6、Eclipse

最受歡迎的IDE，GoClipse插件在Eclipse中添加了IDE功能來支持Go，GoClipse提供了可配置的語法高亮顯示、自動文檔補全、自動編譯以及最重要的實驗調試支持。

7、TextMate

是一個Mac OS下的文本編輯器，可擴展它以突出顯示Go代碼，並提供源代碼片段。

8、Komodo Edit

來自ActiveState的開源代碼編輯器，基於Monzilla 7.0且支持跨平台，支持多種語言，但免費版的Komodo功能有限，它的golang插件komodo-go提供了基本的語法高亮、代碼補全功能。

Golang項目部署3，容器部署

容器部署即使用 docker 化部署 golang 應用程序，這是在雲服務時代最流行的部署方式，也是最推薦的部署方式。

跨平台交叉編譯是 golang 的特點之一，可以非常方便地編譯出我們需要的目標伺服器平台的版本，而且是靜態編譯，非常容易地解決了運行依賴問題。

使用以下指令可以靜態編譯 Linux 平台 amd64 架構的可執行文件：

生成的 main 便是我們靜態編譯的，可部署於 Linux amd64 上的可執行文件。

我們需要將該可執行文件 main 編譯生成 docker 鏡像，以便於分發及部署。 Golang 的運行環境推薦使用 alpine 基礎系統鏡像，編譯出的容器鏡像約為 20MB 左右。

一個參考的 Dockerfile 文件如下：

其中，我們的基礎鏡像使用了 loads/alpine:3.8 ，中國國內的用戶推薦使用該基礎鏡像，基礎鏡像的 Dockerfile 地址： ，倉庫地址：

隨後使用 ” docker build -t main . ” 指令編譯生成名為 main 的 docker 鏡像。

需要注意的是，在某些項目的架構設計中， 靜態文件 和 配置文件 可能不會隨著鏡像進行編譯發布，而是分開進行管理和發布。

例如，使用 MVVM 模式的項目中(例如使用 vue 框架)，往往是前後端非常獨立的，因此在鏡像中往往並不會包含 public 目錄。而使用了 配置管理中心 (例如使用 consul / etcd / zookeeper )的項目中，也往往並不需要 config 目錄。

因此對於以上示例的 Dockerfile 的使用，僅作參考，根據實際情況請進行必要的調整。

使用以下指令可直接運行剛才編譯成的鏡像：

容器的分發可以使用 docker 官方的平台： ，國內也可以考慮使用阿里云： 。

在企業級生產環境中， docker 容器往往需要結合 kubernetes 或者 docker swarm 容器編排工具一起使用。

容器編排涉及到的內容比較多，感興趣的同學可以參考以下資料：