為什么我們要使用Go語言以及如何使用它的
我們SoundCloud是一個使用多種編程語言的公司，雖然我們的技術架構最外層一直使用的是Ruby on Rails，但是在后端，各種各樣的編程語言都有涉及。在這里我想多講一下為什么要使用和如何使用Go這樣一種開源的、剛剛發布其1.0版本的編程語言的。
在我們的公司里，所有的技術人員都是全能選手，而不是專才，這是根植于公司基因文化里的特征。我們希望每個人都能對公司的基礎架構中每一部分都至少有相當的了解。更進一步，我們鼓勵技術人員在個開發團隊間調換，甚至組成新的團隊，使成員跟各團隊的沖突和摩擦盡量減少。在這樣一種代碼共產共有的環境中，非常需要一種表達性強，效率高的語言來降低實施的困難，Go語言證明了它是一種非常適合的語言。
我們已經有好幾個程序員都把Go語言描述為是一種所見即所得(WYSIWYG)的編程語言。這是說，代碼要做的事和它在字面上表達的意思是完全一致的。這種特征對于使軟件無歧義和可維護有著巨大的幫助。Go語言明確的拒絕“helper”習慣用法以及諸如統一訪問原則(Uniform Access Principle)、操作符重載、缺省參數、甚至異常等特征，基本上，這些特征相較于能產生更豐富的表達，它們的歧義性會帶來更大的問題。不否認，這樣的策略會帶來更多的鍵盤敲擊——尤其是，正如大多數參與Go語言項目的新手程序員痛斥的，在異常處理時最麻煩——但是，換來的報答是，還是這些新手程序員，他們能輕易的、迅速的將應用在腦海里形成一個完整的模型。我可以很有信心的告訴大家，從項目開始到提交代碼，Go是我們使用過的效率***的語言。
Go語言嚴格的結構原則和它的“一種事情有且只有一種方法完成”的思想意味著我們無需在風格問題上糾纏不休。在針對Go語言程序的代碼審查上，審查會變得更針對問題，而不是針對語言上的錯綜復雜，這是每個人都愿意看到的。
更值得一提的是，一旦一個程序員對Effective Go有了一個基本掌握，你會發現他們的關注點能非常自然的從“應用目前應該怎樣運行”過度到“應用在理想狀況下應該如何的運行”。是否是后臺的響應緩慢致使整個請求失敗？是否應該只重試一次，不成功就只提供部分的結果？瀏覽器表現異常，我們是否要設置一個250毫秒的超時限制？系統中任何一個外層的行為場景都能用一種直接的、理想化的實現來表示，不需要類庫或框架的支持。去掉抽象層降低了復雜性；直白陳述式、簡單的代碼是更好的代碼。
Go語言還有其它一些非常好的特征，讓我們受益不少。靜態類型和快速編譯使我們能夠在開發過程中做幾乎實時的靜態檢查和單元測試。這也意味我們開發的基于Go語言的系統中的編譯，測試和發布幾乎是一起完成的。
事實上，快速的編譯，快速的測試，快速的相互審查和快速的部署意味著你的一些想法能在一個小時內從白板上的設計變成產品中可運行的程序。例如，Next軟件中的搜索基本功能是由Elastic Search驅動的，但是它接受SoundCloud的管理和交換幾乎全部是Go服務來完成。在驗證過程中，我們認識的，我們需要一種能在某個特殊環境中把索引標志為只讀狀態的方法，需要索引系統能知道并順從這種狀態。在代碼中加入抽象層，開發一個新的入口點正確的檢測這種狀態，修改跟索引相關的行為，為它們寫測試代碼，這一切只用了半個下午的時間。晚上時，這些修改已經部署并運行了好幾個小時了。這樣的速度，尤其是對一種靜態類型的，本地編譯的語言，簡直沒得說了。
我說到了我們的編譯和部署系統。它叫Bazooka，它被設計成一個平臺，用來管理內部服務的部署。(我們很快就會把它開源；關注我們，不要走開！)我們曾通過一個情況復雜的網絡環境升級12-Factor應用，你可以把它當成一個巨大的、復雜的狀態機，隨時都有可能造成數據污染和相互競爭的狀態。對于這種工作，Go語言是最自然的選擇。Go語言很獨特，它有天生的并行安全特征。Bazooka系統的開發人員能夠分析出問題的復雜性而不需要使用那些復雜的輔助工具。Bazooka利用Doozer來協調它的共享狀態，Doozer是世界上唯一一個Paxos開源實現軟件(就我們所知)——它也是用Go語言開發的。
總之，我們在SoundCloud公司維護著都是用Go語言寫成的十幾種服務和十幾種知識庫。當有新的后臺項目時，我慢慢的都會選擇使用Go語言來完成。
你對使用Go語言解決真正問題和開發真正產品感興趣嗎？我們很樂意聽到你的聲音！
英文原文：Go at SoundCloud
