“就算我從來沒有直接接觸過Go並發原語,為了其部署的隨意性,我確信我會用Go重寫所有我的命令行程序。”
這是我以前說過的話。我認為這句話值得寫一篇更詳細的博文。
大多深入了解我的人都知道關於我的兩件事情:
第二個是Bryan Berry給我貼的標簽,引自一個FoodFight早期片段。
有趣的是,這兩件事看起來是矛盾的。
我喜歡學習新的編程語言。這定期會給我帶來不小的沖擊,因為不是個科班的程序員。我沒有去上大學學編程(實際上,我根本沒有讀大學)。我的IT職業生涯幾乎100%集中於運維。所有我接觸過的東西- QA、DBA、 DEV – 都是源於運維領域,用於滿足某些運維操作上的需求。
因此,我驚訝地發現18年後,自己擁有ruby,Python,perl,JAVA的實踐知識,並了解其他一些編程語言。我學習新的編程語言主要是因為“技癢”。
我就是在這種情況下,遇到了Go。
如果你沒聽說過Go,其實有無數的文章,博文和大量新的工具用Go寫成。最新的Linux容器周邊和新的部署模型就是基於Go的。也有一些相當“大”的用Go編寫的項目,如packer等。Mozilla正在用Go構建所有內部工具(據我了解到的是這樣的),很多開發者也在轉向Go。
你需要知道的是,我並不會因為熱度去學習編程語言。比如,我根本就不關心JavaScript和Node。起初,我對Go也沒任何興趣。我認為它只不過是Google的眾多學術實驗中的一個。何況,如果我要接觸一個C風格的編程語言,為什麼我不直接學習C語言呢?
實際上,我用這個路子嘗試為StormPath寫一個PAM模塊。雖然也還滿意,但項目最終很讓人沮喪。
我覺得再嘗試Go的一個原因是Go似乎一直都在我周圍。這至少給我帶來一個競爭者。其次,我使用的部分工具是用Go編寫的,我要修正一些這些工具的問題(尤其是這些工具是新項目,必然會有問題需要修復),我確實需要學習這們新的編程語言。
然而,一個工具把我推到了最後一步 – etcd。
你自己可以通讀etcd,如果你知道我關於 Noah的歷史,你就明白為什麼我對它如此感興趣。
讓我自己吃驚的是,我決定可能我自己也要用Go寫很多工具。
在Dell Enstratius,我的團隊開發的所有內部工具都是用Python寫成的。對我們而言,這是一個實用的選擇:
為什麼我們不用Ruby?考慮到我個人Ruby技能更好並且我們內部也擁有一些Ruby經驗。
我們團隊考慮了以上所有選項,我們全部同意使用Python。我著手寫了一個訪問我們API的庫。這給我們構建工具提供了基礎,同時也作為一個新工具參考項目(如測試,項目結構,可執行腳本等等)。
事情進展的很順利,直到最近一個客戶的情況發生。為了顯而易見的原因,我們努力精簡依賴。有幾個庫讓這件事變得如此順利- requests, envoy。我們也喜歡使用 Fabric來封裝一些東西。
然後,我們遇到一個狀況,一個客戶拒絕我們引入外部的包。因此,雖然我們可以“半死”大部分我們的工具,有些事情就是不能工作。追蹤傳遞的依賴真是痛苦。
這就是導致我上面陳述的原因。
Go,雖然不像Python那麼容易調試,也還非常容易調試。編譯速度很快,測試速度也相當快。但依賴問題才是真正的殺手锏。Go根本就不存在依賴問題。我可以把我編譯好的二進制文件任意移動而不出任何問題,也不需要安裝運行時。在標准庫中也有很多有用的東西。
我也可以在osx,windows或者linux上不做任何更改的編譯相同的代碼。這也比我們使用Python方便。
和我說的一樣,雖然我現在寫的工具一點也沒用上Go的高級並發特性,但是Go確實擁有這個特性,如果我要用,還是很好的。
我們還沒有轉向用Go來構建工具,但我很可能會用的。我已經致力於用Go來寫一個我們API的封裝,因此我也可以重寫其他一些工具。在依賴受限的系統上,這種做法還是很好用的。這就是這篇博文的重點所在。
如果你的工作和運維相關,學習Go沒什麼壞處。
語法簡潔。C帶來的頭痛的問題基本都會消失不見。同時,你也不用擔心系統的Python或者Ruby版本是多少。Go是一個開發bootstrap工具的絕妙語言——因為bootstrap工具的運行環境沒有任何安裝好的依賴。如果你開始使用像docker, packer 或者etcd的工具,Go也會很有幫助。
試試Go吧。