“就算我從來沒有直接接觸過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吧。
