下面是我在2012年六月舊金山Go SF會議上的發言。
這是一個私人談話。我不單是對在這坐的Go開發團隊成員說，我要感謝團隊在推動Go發展上所做的一切。我還想感謝Go SF組織者給了我跟大家交流的機會。
幾個星期前我被問道這個問題：“你被鼓勵轉到Go後遇到最大的驚喜是什麼？”。我立刻知道了答案：雖然我們預期C++程序員會將Go當做一個替代者，然而轉到Go的程序員更多來自於如Python和Ruby等語言，很少有來自C++。
Ken、Robert和我，當我們還是C++程序員時我們設計了一種新的語言來解決我們認為需要用這門新語言來解決的問題。這好像是自相矛盾的，其他C++程序員並不在乎。
下面是我在2012年六月舊金山Go SF會議上的發言。
這是一個私人談話。我不單是對在這坐的Go開發團隊成員說，我要感謝團隊在推動Go發展上所做的一切。我還想感謝Go SF組織者給了我跟大家交流的機會。
幾個星期前我被問道這個問題：“你被鼓勵轉到Go後遇到最大的驚喜是什麼？”。我立刻知道了答案：雖然我們預期C++程序員會將Go當做一個替代者，然而轉到Go的程序員更多來自於如Python和Ruby等語言，很少有來自C++。
Ken、Robert和我，當我們還是C++程序員時我們設計了一種新的語言來解決我們認為需要用這門新語言來解決的問題。這好像是自相矛盾的，其他C++程序員並不在乎。
今天我想來說說是什麼激發我們創建 Go 語言，以及為什麼得出這樣的結論應該是意料之中的事情。我承諾這將是一段更傾向於 Go 語言而不是 C++ 語言的發言，所以即使你不了解 C++ 語言，你也可以從這篇文章中了解一二。
實際上，這篇文章的結論可以概括如下：你認為 less is more 少即多），還是 less is less少即少）？
這裡我用一個真實的案例作為比喻。Bell 實驗室中心原來是用 3 位數字來命名的：111 是物理研究所、127 是計算科學研究所等等。在 20 世紀 80 年代，隨著我們對研究的深入了解，已經不足以用 3 位數字來簡單地命名研究所了。所以，我們的研究中心編號變成了 1127 。 Ron Hardin 半開玩笑地說如果我們真的了解了這個世界，我們可以去掉編號前面的 1 位，從 127 變為 27。當然，管理層不會采納這個玩笑，也並沒有被期望他們這麼做。但是，我認為，Ron 的說法是有道理的。 Less can be more 精簡反而有更深的內涵）。你了解得越深入，你就能夠用更精煉的語言來概括。
記住這個道理。
回到 2007 年 9 月，我正在做一些為一個大型的 Google C++ 項目做一些瑣碎而中心的工作。你可能接觸過這樣的程序，在我們大型分布式編譯集群上編譯這個程序就用了大概 45 分鐘。後來，聽說了在 C++ 標准委員會的 Google 工程師將會進行 C++0x即現在的 C++11）新特性的演講。
在這場 1 個小時的演講裡，我們聽說了 C++0x 計劃中的 35 項新特性。實際上，或許還有更多的，但演講中只描述了其中的 35 項。當然，一些新特性可能很微小，但是演講中的特性卻都十分重要。一些特性非常精妙而難以理解，像右值引用rvalue-reference）；但同時 也有很多 C++ 特色語法，像可變參數模板variadic templates）；而其他一些則非常瘋狂，像用戶定義數據標志user-defined literals）
此刻我問了自己一個問題：C++委員會真的相信C++因為沒有足夠的特性而出問題嗎？當然，作為Ron Hardin玩笑話的變種，簡化編程語言相比於增加語言是更大的進步。這想法是有些可笑，但先記住它。
在那次C++演講前幾個月，我曾給自己一個演講，你可以去YouTube上看，內容是關於我在1980年間創造的一個娛樂性質的並發語言。那個語言叫做Newsqueak，當然它是Go的前驅。
我做那個演講是因為Newsqueak中的一些想法是我在Google工作時錯過的，而我又重新對這些想法進行了思考。我確信它們將使得寫服務器代碼更加簡單，而且Google將會從中受益。
事實上我曾經嘗試去尋找一個方法把這些想法引入C++，但是失敗了。把並發操作和C++的控制結構連接起來太難了，反過來這樣也很難看到真正的優勢。再加上C++讓自己看起來非常難處理，盡管我承認很難使語言真正易用。所以我遺棄了這個想法。
但C++0x演講讓我重新思考。真正困擾我的——我認為也困擾著Ken和Robert——是具有原子類型的新C++內存模型。在一個已經超負荷的類型系統 中加入這樣一個定義微觀細節的集合，讓人感覺是錯的。這看起來也非常短時，因為硬件很可能在下一個十年裡有明顯的變化，把語言和今天的硬件結合這麼緊密將 是不明智的。
會議結束後，我們回到辦公室。繼續開始了新一輪的編譯，然後轉過桌子面對著 Robert，開始詢問那些關注的問題。在編譯結束以前，我們說服了 Ken ，決定自己動手做點什麼。我們並不希望一直用 C++ 寫程序，我們，特別是我，希望在為 Google 寫代碼的時候能夠自然地使用並發編程技術。我們也希望強調“Programming in large”的方向。
我們在白板上寫了很多我們想要的特性。我們從大方向出發，忽略詳細的語法和語義只關注事物的主要部分。
我還保留著在那周裡一個郵件列表，下面是一些節選：
Robert：起點： C語言，解決一些明顯的瑕疵、刪除雜質、增加一些缺少的特性。
Rob：命名為 Go 語言吧，你可以為這個名字想一些原因。但是它已經有不少美好的屬性了。簡單地說，易於書寫。工具命名也容易：goc、gol、goa。如果有一個交互的調試器、解釋器的話，它可以就叫“go”。文件名後綴就是“.go”。
Robert：空接口：interface {}。可以被所有接口實現，所以，這個接口可以代替 void* 的位置。
這時候，我們並沒有完全弄清楚這種語言。舉例來說，我們用了大概一年時間才弄清楚 array 和 slice 的結構。但是在最初的那幾天，很多重要的特性就已經出現了。
注意到 Robert 說 C 語言是起始點，而不是 C++ 語言。我不確定，但我相信他指的是 C 語言，因為當時 Ken 也在。但是實際上，最後我們並不是真的從 C 語言開始擴展。我們完全重新開始了這門語言，稍微從 C 語言借鑒了操作符、括號以及一些普遍的關鍵字。當然，我們也從其他我們所知道的語言中借鑒了很多想法。）在任何情況下，在我看來，我們從基礎上、打破一 切的思路以及重新開始來回應 C++ 語言。我們並不是嘗試設計一個更好的 C++ 、甚至說一個更好的 C 語言。它只是一個對我們所關注的軟件更好的語言。
最後，它當然和 C 或者 C++ 都相當不同。不同點甚至比大家注意到的多。我列舉一下 Go 語言對 C/C++ 語言的關鍵的簡化：
