滿打滿算, 從好友推薦Golang至發(fā)文時(shí), 使用Golang已經(jīng)有1年多了. 這種時(shí)間對(duì)于C/C++ Java這些老者來(lái)說(shuō), 簡(jiǎn)直是菜鳥(niǎo)級(jí)別的經(jīng)驗(yàn)
但作為新生代語(yǔ)言的特點(diǎn)就是實(shí)戰(zhàn). Golang這一年里, 已經(jīng)為項(xiàng)目提供了穩(wěn)定的服務(wù)器和強(qiáng)大的擴(kuò)展能力, 與客戶端的Unity3D里的C#一樣, 都是強(qiáng)大, 極致開(kāi)發(fā)效率代表的優(yōu)秀開(kāi)發(fā)語(yǔ)言.
用途篇
Golang到底拿來(lái)做啥? 我需要么?
高效(性能,開(kāi)發(fā))的服務(wù)器語(yǔ)言. 包括Web, 游戲, App
編寫(xiě)桌面級(jí)UI暫不是很適合
我需要把現(xiàn)在的C++, Python, Erlang等服務(wù)器改成Golang么?
性能有瓶頸, 開(kāi)發(fā)效率低, 有錢(qián)有時(shí)間的話, 完全可以
評(píng)價(jià)篇
聽(tīng)過(guò)太多的人對(duì)Golang的評(píng)價(jià), 大概分為這么幾類:
C/C++性能黨
此類黨員對(duì)任何事物都追求極致的 性能. 還好Golang是直接生成native code, 否則會(huì)被批的體無(wú)完膚. 但是由于Golang底層為并發(fā)和開(kāi)發(fā)效率而做出的一些系統(tǒng), 類似于GC, 調(diào)度器和分配器等, 會(huì)在語(yǔ)言層上損失很多性能. 因此C/C++黨還是有理由批Golang性能低下
Erlang并發(fā)黨
作為電信級(jí)元老, Erlang的模型和架構(gòu)當(dāng)之無(wú)愧, OTP擴(kuò)展性超級(jí)強(qiáng). 完美的Actor模型也讓邏輯編寫(xiě)比OO更加直觀
CSP與Actor區(qū)別僅僅只是在channel的歸屬范圍而已, 但這點(diǎn)細(xì)微差別卻對(duì)兩種語(yǔ)言的開(kāi)發(fā)變的迥然不同
Golang在并發(fā)模型上選擇了CSP, 就是考慮把架構(gòu)的設(shè)計(jì)留給使用者. 像C#一樣建立一個(gè)類庫(kù)的世界, 而不是MFC一樣的框架世界. 讓開(kāi)發(fā)更自由
Erlang的Actor也沒(méi)錯(cuò). 讓開(kāi)發(fā)更直觀, 讓崩潰提前來(lái)到, 盡快處理
Rust黨
Rust在發(fā)文時(shí)已經(jīng)發(fā)布了1.0. 這讓R粉興奮的穿梭于各大技術(shù)論壇和討論群
但Rust的理念在我看來(lái)有點(diǎn)偏執(zhí)了, 一定要把各種錯(cuò)誤在編譯期暴露出來(lái), 所以造出了很多不需要的類型和概念, 連語(yǔ)言都比C語(yǔ)言更符號(hào)話
大白話說(shuō)來(lái), 有點(diǎn)編程經(jīng)驗(yàn)的人看到JavaScript完全看得懂, 但看Rust卻像天書(shū)
對(duì)比同時(shí)期的TypeScript, Dart, Swift. Rust就是有點(diǎn)那么獨(dú)辟蹊徑
該黨黨員經(jīng)常性的用各種特性對(duì)比Golang, 追求單特性的優(yōu)秀.
但其實(shí), Golang本身是一門(mén)完整哲學(xué). 很多語(yǔ)言特性互相之間有關(guān)聯(lián). 有設(shè)計(jì)不當(dāng)?shù)牡胤? 當(dāng)然更多的是完整體系. 不求和其他語(yǔ)言比
只追求解決問(wèn)題的速度
自定義黨
云風(fēng)看過(guò)Golang后, 因?yàn)樵撜Z(yǔ)言本身就是強(qiáng)化版的C, 因此頗受云風(fēng)喜歡. 但在一堆評(píng)價(jià)后, 云風(fēng)還是果斷選擇了C+lua的組合寫(xiě)出的Skynet
雖然不知道原因, 但我猜的話, 畢竟是對(duì)語(yǔ)言本身的可控性還不那么看好
同時(shí), 我們發(fā)現(xiàn)Skynet使用的是Actor模型, 也發(fā)現(xiàn)大神級(jí)的程序員就是有先見(jiàn).
轉(zhuǎn)載請(qǐng)注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy
感觸篇
設(shè)計(jì)
踏入Golang, 就不要嘗試設(shè)計(jì)模式
傳統(tǒng)的OO在這里是非法的, 嘗試模擬只是一種搞笑
把OO在Golang里換成復(fù)合+接口
對(duì)實(shí)現(xiàn)者來(lái)說(shuō), 把各種結(jié)構(gòu)都復(fù)合起來(lái), 對(duì)外暴露出一個(gè)或多個(gè)接口, 接口就好像使用者在實(shí)現(xiàn)模型上打出的很多洞
別怕全局函數(shù), 包(Package)可以控制全局函數(shù)使用范圍.
沒(méi)必要什么都用interface對(duì)外封裝, struct也是一種良好的封裝方法
Golang無(wú)繼承, 因此無(wú)需類派生圖. 沒(méi)有派生這種點(diǎn)對(duì)點(diǎn)的依賴, 因此不會(huì)在大量類關(guān)系到來(lái)時(shí), 形成繁雜不可變化的樹(shù)形結(jié)構(gòu)
容器
用了很長(zhǎng)時(shí)間map, 才發(fā)現(xiàn)Golang把map內(nèi)建為語(yǔ)言特性時(shí), 已經(jīng)去掉了外置型map的api特性. 一切的訪問(wèn)和獲取都是按照語(yǔ)言特性來(lái)做的, 原子化
數(shù)組可以理解為底層對(duì)象, 你平時(shí)用的都是切片, 不是數(shù)組, 切片就是指針, 指向數(shù)組. 切片是輕量的, 即便值拷貝也是低損耗的
內(nèi)存
Golang在實(shí)際運(yùn)行中, 你會(huì)發(fā)現(xiàn)內(nèi)存可能會(huì)瘋漲. 但跑上一段時(shí)間后, 就保持穩(wěn)定. 這和Golang的內(nèi)存分配, 垃圾回收有一定的關(guān)系
現(xiàn)代的編程語(yǔ)言的內(nèi)存管理不會(huì)很粗暴的直接從OS那邊分配很多內(nèi)存. 而是按需的不斷分配成塊的內(nèi)存.
對(duì)于非海量級(jí)應(yīng)用, Golang本身的內(nèi)存模型完全可以撐得下來(lái). 無(wú)需像C++一樣, 每個(gè)工程必做內(nèi)存池和線程池
Channel
Channel和鎖誰(shuí)輕量? 一句話告訴你: Channel本身用鎖實(shí)現(xiàn)的. 因此在迫不得已時(shí), 還是盡量減少使用Channel, 但Channel屬于語(yǔ)言層支持, 適度使用, 可以改善代碼可讀寫(xiě)
轉(zhuǎn)載請(qǐng)注明: 戰(zhàn)魂小筑http://www.shnenglu.com/sunicdavy
錯(cuò)誤
覺(jué)得Golang不停的處理err? 那是因?yàn)槠綍r(shí)在其他語(yǔ)言根本沒(méi)處理過(guò)錯(cuò)誤, 要不然就是根部一次性try過(guò)所有的異常, 這是一種危險(xiǎn)的行為
panic可以被捕獲, 因此編寫(xiě)服務(wù)器時(shí), 可以做到不掛
危險(xiǎn)的interface{}
這東西就跟C/C++里的void*一樣的危險(xiǎn), nil被interface{}包裹后不會(huì)等于nil相等, 但print出來(lái)確實(shí)是nil
模板估計(jì)可以解決容器內(nèi)帶interface{}的問(wèn)題. 但新東西引入, 估計(jì)又會(huì)讓現(xiàn)在的哲學(xué)一些凌亂
初學(xué)Tips
語(yǔ)言學(xué)習(xí)按照官網(wǎng)的教學(xué)走, 跑完基本就會(huì)了
下載一個(gè)LiteIDE, 配合Golang的Runtime,基本開(kāi)環(huán)境就有了
Golang的類庫(kù)設(shè)計(jì)方式和C#/C++都不同, 如果有Python經(jīng)驗(yàn)的會(huì)感覺(jué)毫無(wú)違和感
有一萬(wàn)個(gè)理由造輪子都請(qǐng)住手, 類庫(kù)里有你要的東西
寫(xiě)大工程請(qǐng)搜索: Golang項(xiàng)目目錄結(jié)構(gòu)組織
Golang語(yǔ)言本身本人沒(méi)有發(fā)現(xiàn)bug, 即便有也早就被大神們捉住了. 唯一的一個(gè)感覺(jué)貌似bug的, 經(jīng)常是結(jié)構(gòu)體成員首字母小寫(xiě), 但是json又無(wú)法序列化出來(lái)…
慎用cgo. 官方已經(jīng)聲明未來(lái)對(duì)cgo不提供完整兼容性. 任何一門(mén)語(yǔ)言在早期都需要對(duì)C做出支持, 但后期完善后的不兼容都是常態(tài)