為什么我們需要一門新語言
　　編程語言已經(jīng)非常多，偏性能敏感的編譯型語言有 C、C++、Java、C#、Delphi和Objective-C等，偏快速業(yè)務開發(fā)的動態(tài)解析型語言有 PHP、Python、Perl、Ruby、JavaScript和Lua等，面向特定領域的語言有 Erlang、R和MATLAB等，那么我們?yōu)槭裁葱枰?Go這樣一門新語言呢？
　　在2000年前的單機時代， C語言是編程之王。隨著機器性能的提升、軟件規(guī)模與復雜度的提高，Java逐步取代了C的位置。盡管看起來 Java已經(jīng)深獲人心，但 Java編程的體驗并未盡如人意。歷年來的編程語言排行榜（如圖 0-1所示）顯示， Java語言的市場份額在逐步下跌，并趨近于 C語言的水平，顯示了這門語言后勁不足。
　　圖0-1編程語言排行榜①
　　Go語言官方自稱，之所以開發(fā) Go語言，是因為“近 10年來開發(fā)程序之難讓我們有點沮喪”。這一定位暗示了 Go語言希望取代 C和Java的地位，成為最流行的通用開發(fā)語言。 Go希望成為互聯(lián)網(wǎng)時代的 C語言。多數(shù)系統(tǒng)級語言（包括 Java和C#）的根本編程哲學來源于
　　——————————
　�、�  據(jù)來源： http：//www.tiobe.com/index.php/content/paperinfo/tpci/index.html。
　　C++，將C++的面向?qū)ο筮M一步發(fā)揚光大。但是Go語言的設計者卻有不同的看法，他們認為C++ 真的沒啥好學的，值得學習的是 C語言。C語言經(jīng)久不衰的根源是它足夠簡單。因此， Go語言也要足夠簡單！
　　那么，互聯(lián)網(wǎng)時代的 C語言需要考慮哪些關鍵問題呢？首先，并行與分布式支持。多核化和集群化是互聯(lián)網(wǎng)時代的典型特征。作為一個互聯(lián)網(wǎng)時代的C語言，必須要讓這門語言操作多核計算機與計算機集群如同操作單機一樣容易。其次，軟件工程支持。工程規(guī)模不斷擴大是產(chǎn)業(yè)發(fā)展的必然趨勢。單機時代語言可以只關心問題本身的解決，而互聯(lián)網(wǎng)時代的 C語言還需要考慮軟件品質(zhì)保障和團隊協(xié)作相關的話題。最后，編程哲學的重塑。計算機軟件經(jīng)歷了數(shù)十年的發(fā)展，形成了面向?qū)ο蟮榷喾N學術流派。什么才是最佳的編程實踐？作為互聯(lián)網(wǎng)時代的 C語言，需要回答這個問題。接下來我們來聊聊 Go語言在這些話題上是如何應對的。
　　并發(fā)與分布式
　　多核化和集群化是互聯(lián)網(wǎng)時代的典型特征，那語言需要哪些特性來應對這些特征呢？第一個話題是并發(fā)執(zhí)行的“執(zhí)行體”。執(zhí)行體是個抽象的概念，在操作系統(tǒng)層面有多個概念與之對應，比如操作系統(tǒng)自己掌管的進程（ process）、進程內(nèi)的線程（ thread）以及進程內(nèi)的協(xié)程
　�。╟oroutine，也叫輕量級線程）。多數(shù)語言在語法層面并不直接支持協(xié)程，而通過庫的方式支持的協(xié)程的功能也并不完整，比如僅僅提供協(xié)程的創(chuàng)建、銷毀與切換等能力。如果在這樣的協(xié)程中調(diào)用一個同步 IO操作，比如網(wǎng)絡通信、本地文件讀寫，都會阻塞其他的并發(fā)執(zhí)行協(xié)程，從而無法真正達到協(xié)程本身期望達到的目標。
　　Go語言在語言級別支持協(xié)程，叫 goroutine。Go語言標準庫提供的所有系統(tǒng)調(diào)用（ syscall）操作，當然也包括所有同步 IO操作，都會出讓 CPU給其他goroutine，這讓事情變得非常簡單。我們對比一下Java和Go，近距離觀摩下兩者對“執(zhí)行體”的支持。
　　為了簡化，我們在樣例中使用的是 Java標準庫中的線程，而不是協(xié)程，具體代碼如下：
　　public class MyThread implements Runnable {
　　String arg；
　　public MyThread(String a) { arg = a； }
　　public void run() { // ... }
　　public static void main(String[] args) { new Thread(new MyThread(“”test“”)).start()； // ...
　　}
　　}
　　相同功能的代碼，在 Go語言中是這樣的：
　　func run(arg string) {
　　// ...
　　}
　　func main() {
　　go run(“”test“”)
　　...
　　}
　　對比非常鮮明。我相信你已經(jīng)明白為什么 Go語言會叫 Go語言了：Go語言獻給這個時代最好的禮物，就是加了 go這個關鍵字。當然也有人會說，叫 Go語言是因為它是 Google出的。好吧，這也是個不錯的閑聊主題。
　　第二個話題是“執(zhí)行體間的通信”。執(zhí)行體間的通信包含幾個方式：
　　·執(zhí)行體之間的互斥與同步
　　·執(zhí)行體之間的消息傳遞
　　先說·執(zhí)行體之間的互斥與同步·。當執(zhí)行體之間存在共享資源（一般是共享內(nèi)存）時，為保證內(nèi)存訪問邏輯的確定性，需要對訪問該共享資源的相關執(zhí)行體進行互斥。當多個執(zhí)行體之間的邏輯存在時序上的依賴時，也往往需要在執(zhí)行體之間進行同步�；コ馀c同步是執(zhí)行體間最基礎的交互方式。
　　多數(shù)語言在庫層面提供了線程間的互斥與同步支持，那么協(xié)程之間的互斥與同步呢？呃，不好意思，沒有。事實上多數(shù)語言標準庫中連協(xié)程都是看不到的。
　　再說·執(zhí)行體之間的消息傳遞·。在并發(fā)編程模型的選擇上，有兩個流派，一個是共享內(nèi)存模型，一個是消息傳遞模型。多數(shù)傳統(tǒng)語言選擇了前者，少數(shù)語言選擇后者，其中選擇·消息傳遞模型·的最典型代表是 Erlang語言。業(yè)界有專門的術語叫“ Erlang風格的并發(fā)模型”，其主體思想是兩點：一是“輕量級的進程（ Erlang中‘進程’這個術語就是我們上面說的‘執(zhí)行體’）”，二是“消息乃進程間通信的唯一方式”。當執(zhí)行體之間需要相互傳遞消息時，通常需要基于一個消息隊列（message queue）或者進程郵箱（ process mail box）這樣的設施進行通信。
　　Go語言推薦采用“ Erlang風格的并發(fā)模型”的編程范式，盡管傳統(tǒng)的“共享內(nèi)存模型”仍然被保留，允許適度地使用。在 Go語言中內(nèi)置了消息隊列的支持，只不過它叫通道（ channel）。兩個goroutine之間可以通過通道來進行交互。
　　軟件工程
　　單機時代的語言可以只關心問題本身的解決，但是隨著工程規(guī)模的不斷擴大，軟件復雜度的不斷增加，軟件工程也成為語言設計層面要考慮的重要課題。多數(shù)軟件需要一個團隊共同去完成，在團隊協(xié)作的過程中，人們需要建立統(tǒng)一的交互語言來降低溝通的成本。規(guī)范化體現(xiàn)在多個層面，如：
　　·代碼風格規(guī)范
　　·錯誤處理規(guī)范
　　·包管理
　　·契約規(guī)范（接口）
　　·單元測試規(guī)范
　　·功能開發(fā)的流程規(guī)范
　　Go語言很可能是第一個將代碼風格強制統(tǒng)一的語言，例如 Go語言要求 public的變量必須以大寫字母開頭，private變量則以小寫字母開頭，這種做法不僅免除了public、private關鍵字，更重要的是統(tǒng)一了命名風格。
　　另外，Go語言對 { }應該怎么寫進行了強制，比如以下風格是正確的：
　　if expression { ... }
　　但下面這個寫法就是錯誤的：
　　if expression { ... }
　　而C和Java語言中則對花括號的位置沒有任何要求。哪種更有利，這個見仁見智。但很顯然的是，所有的 Go代碼的花括號位置肯定是非常統(tǒng)一的。最有意思的其實還是 Go語言首創(chuàng)的錯誤處理規(guī)范：
　　f， err ：= os.Open(filename)
　　if err ！= nil { log.Println(“”Open file failed：““， err) return
　　} defer f.Close() ... // 操作已經(jīng)打開的 f文件
　　這里有兩個關鍵點。其一是 defer關鍵字。 defer語句的含義是不管程序是否出現(xiàn)異常，均在函數(shù)退出時自動執(zhí)行相關代碼。在上面的例子中，正是因為有了 defer，才使得無論后續(xù)是否會出現(xiàn)異常，都可以確保文件被正確關閉。其二是 Go語言的函數(shù)允許返回多個值。大多數(shù)函數(shù)的最后一個返回值會為 error類型，以在錯誤情況下返回詳細信息。 error類型只是一個系統(tǒng)內(nèi)置的interface，如下：
　　type error interface { Error() string }
　　有了error類型，程序出現(xiàn)錯誤的邏輯看起來就相當統(tǒng)一。在Java中，你可能這樣寫代碼來保證資源正確釋放：
　　Connection conn = ...；
　　try { Statement stmt = ...； try {
　　ResultSet rset = ...； try {
　　... // 正常代碼 } finally {
　　rset.close()；
　　} } finally {
　　stmt.close()；
　　} } finally {
　　conn.close()； }
　　完成同樣的功能，相應的 Go代碼只需要寫成這樣：
　　conn ：= ... defer conn.Close()
　　stmt ：= ... defer stmt.Close()
　　rset ：= ... defer rset.Close() ... // 正常代碼
　　對比兩段代碼， Go語言處理錯誤的優(yōu)勢顯而易見。當然，其實 Go語言帶給我們的驚喜還有很多，后續(xù)有機會我們可以就某個更具體的話題詳細展開來談一談。
　　編程哲學
　　計算機軟件經(jīng)歷了數(shù)十年的發(fā)展，形成了多種學術流派，有面向過程編程、面向?qū)ο缶幊�、函�?shù)式編程、面向消息編程等，這些思想究竟孰優(yōu)孰劣，眾說紛紜。
　　C語言是純過程式的，這和它產(chǎn)生的歷史背景有關。 Java語言則是激進的面向?qū)ο笾髁x推崇者，典型表現(xiàn)是它不能容忍體系里存在孤立的函數(shù)。而 Go語言沒有去否認任何一方，而是用批判吸收的眼光，將所有編程思想做了一次梳理，融合眾家之長，但時刻警惕特性復雜化，極力維持語言特性的簡潔，力求小而精。
　　從編程范式的角度來說， Go語言是變革派，而不是改良派。對于C++、Java和C#等語言為代表的面向?qū)ο螅?OO）思想體系，Go語言總體來說持保守態(tài)度，有限吸收。首先，Go語言反對函數(shù)和操作符重載（ overload），而C++、Java和C#都允許出現(xiàn)同名函數(shù)或操作符，只要它們的參數(shù)列表不同。雖然重載解決了一小部分面向?qū)ο缶幊蹋?OOP）的問題，但
　　同樣給這些語言帶來了極大的負擔。而 Go語言有著完全不同的設計哲學，既然函數(shù)重載帶來了負擔，并且這個特性并不對解決任何問題有顯著的價值，那么 Go就不提供它。其次，Go語言支持類、類成員方法、類的組合，但反對繼承，反對虛函數(shù)（ virtual function）和虛函數(shù)重載。確切地說， Go也提供了繼承，只不過是采用了組合的文法來提供：
　　type Foo struct { Base ...
　　}
　　func (foo *Foo) Bar() { ... }
　　再次，Go語言也放棄了構(gòu)造函數(shù)（ constructor）和析構(gòu)函數(shù)（destructor）。由于Go語言中沒有虛函數(shù)，也就沒有 vptr，支持構(gòu)造函數(shù)和析構(gòu)函數(shù)就沒有太大的價值。本著“如果一個特性并不對解決任何問題有顯著的價值，那么 Go就不提供它”的原則，構(gòu)造函數(shù)和析構(gòu)函數(shù)就這樣被Go語言的作者們干掉了。
　　在放棄了大量的 OOP特性后，Go語言送上了一份非常棒的禮物：接口（ interface）。你可能會說，除了 C這么原始的語言外，還有什么語言沒有接口呢？是的，多數(shù)語言都提供接口，但它們的接口都不同于 Go語言的接口。
　　Go語言中的接口與其他語言最大的一點區(qū)別是它的非侵入性。在 C++、Java和C#中，為了實現(xiàn)一個接口，你需要從該接口繼承，具體代碼如下：
　　class Foo implements IFoo { // Java文法 ... }
　　class Foo ： public IFoo { // C++文法 ... }
　　IFoo* foo = new Foo；
　　在Go語言中，實現(xiàn)類的時候無需從接口派生，具體代碼如下：
　　type Foo struct { // Go 文法 ... }
　　var foo IFoo = new(Foo)
　　只要Foo實現(xiàn)了接口IFoo要求的所有方法，就實現(xiàn)了該接口，可以進行賦值。 Go語言的非侵入式接口，看似只是做了很小的文法調(diào)整，實則影響深遠。其一，Go語言的標準庫再也不需要繪制類庫的繼承樹圖。你只需要知道這個類實現(xiàn)了哪些
　　方法，每個方法是啥含義就足夠了。其二，不用再糾結(jié)接口需要拆得多細才合理，比如我們實現(xiàn)了 File類，它有下面這些方法：
　　前言：為什么我們需要一門新語言
　　Read(buf []byte) (n int， err error) Write(buf []byte) (n int， err error) Seek(off int64， whence int) (pos int64， err error) Close() error
　　那么，到底是應該定義一個 IFile接口，還是應該定義一系列的 IReader、IWriter、 ISeeker和ICloser接口，然后讓File從它們派生好呢？事實上，脫離了實際的用戶場景，討論這兩個設計哪個更好并無意義。問題在于，實現(xiàn) File類的時候，我怎么知道外部會如何用它呢？
　　其三，不用為了實現(xiàn)一個接口而專門導入一個包，而目的僅僅是引用其中的某個接口的定義。在Go語言中，只要兩個接口擁有相同的方法列表，那么它們就是等同的，可以相互賦值，如對于以下兩個接口，第一個接口：
　　package one
　　type ReadWriter interface {
　　Read(buf [] byte) (n int， err error)
　　Write(buf [] byte) (n int， err error)
　　}
　　第二個接口：
　　package two
　　type IStream interface {
　　Write(buf [] byte) (n int， err error)
　　Read(buf [] byte) (n int， err error)
　　}
　　這里我們定義了兩個接口，一個叫 one.ReadWriter，一個叫 two.IStream，兩者都定義了Read()和Write()方法，只是定義的次序相反。 one.ReadWriter先定義了 Read()再定義 Write()，而two.IStream反之。
　　在Go語言中，這兩個接口實際上并無區(qū)別，因為：
　　·任何實現(xiàn)了 one.ReadWriter接口的類，均實現(xiàn)了 two.IStream；
　　·任何one.ReadWriter接口對象可賦值給 two.IStream，反之亦然；
　　·在任何地方使用 one.ReadWriter接口，與使用 two.IStream并無差異。所以在Go語言中，為了引用另一個包中的接口而導入這個包的做法是不被推薦的。因為多引用一個外部的包，就意味著更多的耦合。
　　除了OOP外，近年出現(xiàn)了一些小眾的編程哲學， Go語言對這些思想亦有所吸收。例如， Go語言接受了函數(shù)式編程的一些想法，支持匿名函數(shù)與閉包。再如， Go語言接受了以 Erlang語言為代表的面向消息編程思想，支持 goroutine和通道，并推薦使用消息而不是共享內(nèi)存來進行并發(fā)編程。總體來說， Go語言是一個非�，F(xiàn)代化的語言，精小但非常強大。
　　小結(jié)
　　在十余年的技術生涯中，我接觸過、使用過、喜愛過不同的編程語言，但總體而言， Go語言的出現(xiàn)是最讓我興奮的事情。我個人對未來 10年編程語言排行榜的趨勢判斷如下：
　　□·Java語言的份額繼續(xù)下滑，并最終被 C和Go語言超越；
　　□·C語言將長居編程榜第二的位置，并有望在 Go取代Java前重獲語言榜第一的寶座；
　　□·Go語言最終會取代 Java，居于編程榜之首。
　　由七牛云存儲團隊編著的這本書將盡可能展現(xiàn)出 Go語言的迷人魅力。希望本書能夠讓更多人理解這門語言，熱愛這門語言，讓這門優(yōu)秀的語言能夠落到實處，把程序員從以往繁雜的語言細節(jié)中解放出來，集中精力開發(fā)更加優(yōu)秀的系統(tǒng)軟件。
　　許式偉 2012年3月7日