卡門（Carmen）和喬恩（Jon）與羅布·派克（Rob Pike）和羅伯特·格里塞梅爾（Robert Griesemer）（Go的創造者）討論了它的起源，增長，影響力和未來。這是一部史詩般的劇集，深入探討了Go語言的歷史和細節，以及Go語言的方式和原因，以及他們在創建這種出色的編程語言過程中所做的選擇。
歡迎大家，去時間！今天我們爲您舉辦一場非常特別的表演。今天是第100集。嗚嗚！我們有一些很棒的客人。今天的主持人是卡門·安多（Carmen Andoh，我，我和我），以及喬恩·卡爾霍恩（Jon Calhoun）。
大家好！
今天我們的兩位嘉賓是Go編程語言的創建者Rob Pike和Robert Griesemer。歡迎您，我們很榮幸有您！
大！感謝您邀請我們。
大家好。
肯也應該在這裏，但他正在希臘度假，所以……他贏了。
（笑）對。第三個–我試圖弄個帽子戲法，然後…是的，他說他有很好的藉口，他正在希臘度假。我們希望自己首先在希臘，但是我們很高興能獲得GoTime的安慰獎……[笑]也許吧。也許不吧。
顯然，我們的預算不允許我們所有人飛往希臘。
是的，那太酷了。
你問了嗎？
不，我應該有，但我認爲預算不會允許這樣做。預算很小。
你好，羅伯特。
大家好。很高興來到這裏。
好吧，讓我們開始吧。讓我們談談Go。我想人們想知道的第一件事就是，在初期，當您決定“嘿，讓我們開始編寫一種編程語言”時，它是什麼樣的。
羅伯特，我想這是我的錯，對吧？我不確定它是如何開始的，但是我們想講的故事是我們剛剛看到有關新版本，新版本的C ++的討論，這是大多數服務器軟件的編寫語言。 Google…而且我一直在思考C ++的不合適之處，因爲它缺乏對我們正在獲得的新型多核計算機的支持，以及我想如何回到多年以前探索的一些想法。併發編程…然後我們坐在一起–羅伯特和我共用一個辦公室，在2007年9月的某個時候，我想我真的把椅子轉給了羅伯特，然後我說：“嘿，羅伯特，我們應該爲此做些事情。”
我們聊了幾分鐘，然後肯在下一個辦公室，所以我跑去找肯說：“你想幫忙嗎？”他說是的，就是這樣。羅伯特，這讓您記憶猶新嗎？
是的，所以我認爲C ++可能要晚一點了-我不確定100％-但肯定是在9月。我昨天看了看我的筆記，我認爲那一定是星期五下午，或者也許是前一天，因爲我們在其中一個下午進行了集思廣益的會議中有一個三小時的會議室。我的記憶有些不同。我認爲您正在開發一個非常令人沮喪的C ++程序，並且又遇到了幾分鐘的編譯時暫停，然後…
[ 00：04：22.21 ] 45分鐘。
好吧，45分鐘，你並不特別高興。我們中的一個人說：“我們應該停止這樣做或抱怨或採取任何其他措施，並嘗試對此做某事。”我想我們倆都或多或少立即決定“是的，我們應該對此真正採取行動。”
是的，那龐大的構建也是其中的一部分，而我試圖做的是處理這樣一個事實，即我不允許使用線程來解決程序中的併發問題，因爲在這種情況下C ++庫無法正常工作方式，並且樣式規則禁止在二進制文件中使用線程。所以我當時在做體操，這很容易做錯，做一件讓我感到震驚的事情很簡單……然後，每當我碰到任何東西時，我都必須等待45分鐘才能在龐大的分佈式編譯集羣上進行另一次構建。在某個時候，我的士氣剛好崩潰。我們不得不做點什麼……但是我清楚地記得轉過椅子說：“羅伯特，救命！”
每當你們開始時，您是立即投入全職學習，還是像20％類型的項目或其他東西？因爲我想對於大多數人來說，僅僅放棄他們正在做的事情而去學習一種語言是非常困難的。這是一項艱鉅的任務。那麼那是什麼-只是部分地“讓我每個星期五都在這20％上工作”還是其他？
我想我們關上門開始聊天。在那之前，我實際上已經考慮了一些語言問題。我以前用其他語言工作過。我有很多我從未寫下過的想法，但是它們已經在我腦海裏呆了幾年了。我一直在想這個問題……並不是真的在考慮做些什麼，更像是一個私人寵物項目。
對我來說，絕對不可能只做另一個項目，因爲我實際上剛剛開始了另一個新項目，這是Google正在爲Chrome進行的即將到來的新Javascript實現的V8解釋器……因此，實際上，我試圖將其壓縮，直到最終設法讓我的經理接受這樣一個事實，即也許我想做其他事情。
我們絕對仍然有真正的工作，因此我們不得不將其壓縮。。但是我必須說，當時我們的老闆-至少是我的老闆和Ken的老闆-當時從貝爾實驗室跟我們一起來的比爾·科夫蘭（Bill Coughran）是在早期提供了極大的支持，使我們可以自由地在此方面做大量的時間，並且不得不爲我們認爲應該做其他事情的人辯護幾次。但是大約在六個月到一年之後，我想我們都全職了。
是的，是的。我同意羅布在這裏的評估。我們非常感謝Bill Coughran，因爲如果他沒有給我們這樣做的餘地，這可能就不會發生。
Bill在貝爾實驗室與您同在，並且已經與您在貝爾實驗室的其他事業合作過，所以他有點理解您的能力以及如果任由自己創造的東西。設備。
是的，比爾是我有過的最好的經理。他和我在1980年相隔一兩個星期才加入貝爾實驗室，所以我們彼此非常瞭解。我們倆都在那裏的計算機科學研究中心工作了20多年。在某個時候，他升任該中心主任。我不記得他當導演時的確切角色，但是我們確實在那裏進行了一個大型項目。計劃9是在比爾（Bill）的支持下提出的，諸如此類，還有其他一些內部聯網項目。
[ 00：08：23.04 ]因此，我們已經與他一起擔任經理很多工作，我非常努力地招募他加入Google，因爲他們需要像Bill這樣的人，而我希望像Bill這樣的人成爲我的經理。是的，他是其中的重要組成部分。我認爲，在這些故事中，人們常常忽略了合適的人幫助做某事而不真正參與其中的重要性，而比爾真的很擅長。這就是爲什麼他是如此出色的經理。
那很棒。所以-
前進。
不，我讓你。
我只是要多補充一點時間表。因此，到2008年4月，肯一直在或想要從事一個編譯器的工作。第一個是編譯爲C代碼，然後我們使用C編譯器進行編譯，因爲它更容易上手……儘管這種持續時間不是很長。我想是在2008年4月-當時我在悉尼，我想羅伯特當時來到悉尼，我們有一間會議室，視頻通話專職設在肯的辦公室，而肯的辦公室仍在加利福尼亞，我們三個人一起編寫了規範並實現了編譯器。我想，Ken在編譯器上工作，而我在一個規範上工作，來回一週或兩週。
兩個禮拜
但這是規範發生的時間。是的，幾個星期。因此，我們真的開始了大約六個月的頭腦風暴和大致塑形。我們所做的第一批重要工作之一-也許是我們所做的第一項重要工作-是我們編寫了語言的正式規範，我認爲這是項目成功的關鍵部分。
那就對了。
其中最重要的事情之一是伊恩·泰勒（Ian Taylor），他也是Google的一員，看到了規範，並決定他要爲此編寫一個編譯器。因此，有一天他走進我們的辦公室，說道：“哦，順便說一句，我已經爲您的語言編寫了一個編譯器。”對於我們來說，這真是令人驚訝的時刻。當然，他已成爲團隊的一員，他現在仍在從事Go的研究。
是的，那完全是出乎意料的。因此，在悉尼，我認爲我們已經寫下了很多文字，但不是很正式，如果我沒記錯的話，我們花了很多時間試圖弄清楚如何正確繪製地圖。我們想以某種方式將地圖映射到該語言中，但我們不太瞭解該怎麼做，我認爲是您，Rob，他最終說：“我們應該努力使它們在90％的情況下都能正常工作，對於其他情況，我們可能不應該使事情變得更復雜。”我認爲，事後看來這是一個非常好的決定。
我不記得了，但是聽起來像我。我們還努力使數組正常工作，最終變成了切片。
對。我認爲那花了一點時間。
是的 而且我認爲切片是在我住院的時候發生的……因爲幾個月後我發生了一次嚴重事故，並且住院了一段時間。當我出來的時候，我認爲那是片刻的事情。我不參與其中，但是我對結果感到非常滿意。
切成薄片–我認爲一些關鍵思想是肯在那裏的思想。
是的，那是絕對正確的。
因此，當您說這些事情很難弄清楚時，是因爲您曾經看到過其他語言以一種您認爲不正確的方式來做到這一點，還是因爲您已經見過其他語言可以做數組，並且有一些示例可以複製，但您選擇不復制？
[ 00：11：50.18 ]是的，您必須確定語義是什麼。至少Ken和我當然來自相當沉重的C語言思維方式，因此我們花了一些時間才放棄了其中的一些想法。但是我確實想要C所沒有的一件事，我想Ken和Robert會同意，那就是我們想確保我們有某種方式來做可變長度數組，或者我們現在稱之爲切片……而如何在C內存模型中執行此操作有些棘手。
顯然，還有許多其他語言已經完成了類似的工作，但是我們必須決定哪些子集或如何選擇它們所支持的功能的行爲，以使其與我們嘗試構建的語言模型最匹配。僅僅從其他語言中獲取功能並將它們粘合在一起，就無法獲得良好的設計。相反，我們嘗試爲所有部分協同工作的語言建立一個一致的模型。地圖和切片很困難，因爲至少從Ken和我的角度來看，我們必須做的事情與通常考慮這些事情的方式大不相同。羅伯特可以爲自己說話。
是的，所以我來自完全不同的背景。我不一定會和C一起成長。我與Pascal及其繼承人一起成長。在其中一個繼承人中，有Modula 2，然後是Oberon，他們有一個相似的功能，即所謂的開放數組，它的大小是動態的……但是它們只能作爲函數參數傳遞，所以說話。因此，根據要傳遞的數組的類型，函數中有一個開放大小的數組，一個動態大小的數組。很好，但是它沒有我們想要的靈活，因此花了一些時間才能從C的各種想法（也許是從這個想法）獲得到現在的狀態。
映射和切片都具有該屬性，至少在基本級別上，這對於C中的任何內容都不是正確的，這是內存表示在某種程度上對用戶不可見。它們具有更復雜的結構來保存數組的長度，映射的哈希桶或其他內容。在C語言中，從根本上講，您從沒有像這樣的東西……這是一個挑戰。後來證明這是一個挑戰，因爲要使切片和地圖正常工作，必須將它們作爲描述符的地址傳遞到描述符塊中，並且我們一直在努力如何最好地向用戶隱藏這些指針。
有一陣子它們很明顯，但是有點不舒服，所以最終我們崩潰了，把它們完全隱藏了。但是要做到這一點，我們有點不得不改變內存分配的工作方式，這就是爲什麼有兩個分配器的原因：new和make。我對此從未感到滿意；我認爲沒有人真的對這一切的實現感到滿意……但是在實踐中還可以。
實際上，當Russ出現並決定我們可以在字面上使用地址創建運算符時，可以擺脫新的情況時，它實際上要好一些。那整理了一些東西。因此，大多數人只看到現在做；他們再也看不到新東西。這可能是針對此受衆的一些特定內容，但是…
不，太好了。
沒關係。
…就是這樣。
我認爲這是該觀衆的播客。您提到了一些令人驚訝的時刻，也提到了成爲Go歷史的歷史要點的時刻。首先是伊恩（Ian）到來，讓您在辦公室裏感到驚訝，並說：“嘿，您編寫的規範-我已經爲它準備了一個編譯器。”還有其他時刻可以讓您記住您感覺像拐點或轉折點的地方嗎？在那些早年？
Russ在Ian之後加入了。他曾與Jeff Dean一起在Google實習。他做了一個代碼搜索外部啓動程序，作爲一名實習生，這真是太了不起了……我曾在貝爾實驗室與他一起工作過。他是Bell Labs聲學部門其他經理之一的兒子，我認爲不是計算機領域的。但是他掛在一羣貝爾實驗室的孩子周圍，我認識他已有一段時間了。我認爲他的名字至少出現在我和布萊恩·克尼根（Brian Kernighan）所寫的一本書中……而且我非常努力地努力讓他來。
[ 00：16：13.04 ]我想我實際上是在悉尼，大約在羅伯特（Robert）在那兒的時候，我們正在編寫規範，對拉斯（Russ）進行視頻採訪，告訴他我們在做什麼，以說服他來幫助我們。我們……他決定來。
因此，我認爲他大約在2008年中期出現，並加入了團隊，對清理我們遺留下來的一些雜物確實起到了很大作用，並確實幫助我們將其推向了某個地方。所以他的到來是一件大事。
那時我們只有五歲，而我們五個人一起工作了很長時間。我認爲從那時起至2009年發佈會之間，我們僅增加了一些幫助人員。聽起來像羅伯特嗎？
是的 我認爲大約在2009年，我們至少有了亞當·蘭利，然後又有一兩個……
但是他只是在幫助。儘管他爲我們做了很多工作，但他並不是正式加入小組。我們很幸運。
那是對的。
他做了很多加密工作，並幫助我們建立了第一個網站……類似的事情。
是的是的。是的，我想我們是五六歲，是的。有一個女人-不幸的是，我忘記了她的名字。
是的，珍妮·金。是。
這就是所有預開放源代碼。您是否想談一談2009年11月10日這一盛大的一天，當它開源時的旅程？
我們知道，如果我們能夠做到這一點，它將成爲開源的…因此我們計劃將其作爲開源版本。但是我們希望能夠做到正確或儘可能接近正確，然後再向世人展示。我們啓動它大約需要兩年的時間。在過去的幾個月裏，儘管我們並沒有擺脫一切，但我們還是非常急於清理一切讓我們感到尷尬而無法放開的東西。
這些常見的問題-從公司內部發起，我們必須處理商標，專利和所有無關緊要的事情才能獲得許可權。我會說，儘管谷歌在開源軟件方法方面絕對是太棒了，而且從我的經驗來看，與從AT＆T內部發布東西相比，從谷歌內部做起來要容易得多。但是要做到這一點，我們必須決定核心庫中必須包含哪些內容。亞當爲我們做加密術真是太棒了，因爲它啓用了TLS和其他類似的功能。實際上，Go已經成爲許多加密工作的主要支柱，這在很大程度上要歸功於Adam。
我們必須建立一個網站，以便人們可以看到它。我們必須制定規範，必須處理內容管理系統…我們從SVN開始，然後轉移到Perforce，因爲這是Google內部使用的方法。但是後來Git開始發生。我認爲Go的創建早於GitHub，而不是Git本身。然後我們運行了Mercurial，因爲那是Google的開源產品處理的……所以，我認爲我們使用Mercurial已有2到3年了，一旦很明顯那是未來，我們最終就改用Git。
因此，Go實際上擁有四個內容管理系統-SVN，Perforce，Mercurial和Git。這是熱愛社區的一部分-不變就是不變。
這就引出了一個很好的問題，那就是一旦您將其發佈給開源，既然您有一個社區加入並提出他們的意見並共同創造，那麼這如何改變動態？
好吧，我認爲一開始反應就分爲“哇，這太好了或很有趣”和“這太可怕了”。然後我就慢慢地將它帶走了……
[ 00：20：04.05 ]我認爲很多人在我們首次發佈它時並不瞭解這一點。這看起來不像是一種有趣的語言。“爲什麼會這樣？爲什麼它沒有我期望的所有這些功能？”等等。語言對我們來說的重點是，我們試圖使我們更輕鬆地構建我們在日常生活中編寫的軟件，並且我們認爲我們並不需要所有的複雜性就能完成一件好事。的工作。
但是一旦人們開始使用它-我認爲仍然存在仇恨，但令人高興的是看到這種心情從“這毫無價值”逐漸轉變爲“實際上，這還可以”到“哇，這太好了！”真正發生事情花了幾年時間。
第一個GopherCon發射後已經走了幾年，我記得當時有500人左右的那個房間裏的感覺，所有人都很興奮。想到我和羅伯特和肯因爲我們做了一些事情而把這個人帶進一個房間，真是一種了不起的感覺。這真是一件很棒的事情。但是我們永遠做不到–花費了這些時間才進入了一個社區。它不是一夜之間發生的，它是漸進的。
是的是的。至少對我來說，這很有趣，當我想到第一個GopherCon時……我認爲我們不太確定這是否真實，因爲從某種意義上說，我們與該事件無關。我們沒有組織它，但是顯然我們是受邀的。。。當我們出現在那兒時，還不清楚要期待什麼。“這會是一件大事嗎？一個房間裏將要坐24個人嗎？”結果是有數百人和一個組織得很好的活動，這是一個很大的積極驚喜。
真的很有趣。
很有趣，是的。我認爲在這一點上也有所幫助的是，不久前開始流行的Docker實際上將Go用於其許多軟件。我想，也許是第一個GopherCon，給了我們第一個重大突破。你同意嗎？我不確定。
是的，Docker是我們的殺手級應用程序，因爲它是用Go編寫的，它運作良好，並且成爲了現在所謂的雲計算的核心……我們過去僅將其稱爲系統編程或服務器。而且其中一項關鍵技術是用Go語言編寫的，這一事實證明了該語言對於許多人來說是合理的。我認爲這實際上是一門非常好的語言。這是我們在將語言組合在一起時所考慮的事情，儘管我們自己並未這樣做。
後來，Kubernetes又出現了，這一次來自Google。但是用您的語言編寫出色的軟件是使一種語言取得成功的真正重要組成部分。如果沒有編寫任何語言，那麼語言的好壞並不重要。
你們是否知道Docker團隊在開始時就在Go中編寫它？您是在積極地與他們互動，還是在某種程度上令人震驚？
不，我們沒有參與。後來我們發現了。我遇到了所羅門；他是在Docker上工作的那個人……我想他是團隊的負責人，不過我不確定。所羅門·海克斯（Solomon Hykes）。他在某個時候來到了位於舊金山的Google辦公室，我們聊天了，但這是我第一次見到他，也是我第一次真正與任何人交談。但這在當時已經很確定了。
在一次會議後，我確實在YouTube視頻上看到了一個演示，並且可以說這是我眼前的未來。這是一個很大的問題。Docker是一項非常不錯的技術。Google在操作系統級別上爲內部系統工作做了一些工作，並在其上面放置了一個非常漂亮的用戶界面並進行了打包，以使其實際上可用於日常工作，我認爲是一個非常不錯的項目。這變成了一個不錯的大型項目，並啓用了Kubernetes以及我們今天用來運行大型系統的所有其他雲級別的東西。
[ 00：24：27.28 ]
因此，在經歷了這一重大突破之後，有哪些（如果您還記得的話）成長中的煩惱是什麼？現在Go開始被採用，現在是雲計算的語言了嗎？您認爲您會想到什麼成長的煩惱嗎？或者，換句話說，考慮到那些不斷增長的痛苦，您是否希望做其他任何事情？
嗯，從來沒有什麼完美的……我想更改的語言有很多東西，但是也許我不應該在這裏深入探討。我確實認爲該團隊並未真正做好與開源社區進行交互的準備，這意味着什麼。Ian是我們中唯一在開放源代碼世界中度過了很多時間的人，他所做的不只是他在社區中所佔的份額。
我們花了很長時間才瞭解成爲開源社區一部分的意義，擁有一個基本上由公司支付的項目，但是有很多開源貢獻者……實際上，我們有很多很棒的開源發展發生得很早。Windows的移植工作完全由外部貢獻者完成，這真是太好了……社區的意見至關重要。
我認爲有時候人們會認爲Google控制得太多，這是他們的觀點，但是我不同意。我認爲他們低估了團隊聽取開源社區所說的話，閱讀所有問題，很好地處理所有問題的程度……有時不是很好，但是後來就解決了。
[ 00：28：02.06 ]當有成千上萬的人時，這是一個非常具有挑戰性的事情，現在，據信世界上有數百萬的Go程序員。他們都對這件事以及如何聽取意見，但也要確保您正確把握項目的靈魂-我認爲對此沒有任何簡單的答案。我認爲很多人認爲這很瑣碎，您只是接受了每個人想要的東西……但是那樣的話您就不會擁有Go，而您會擁有其他東西。這確實很棘手，這是非常困難的平衡行爲。
我懷疑部分人有這種感覺的部分原因是因爲，就像我自己一樣，我在一個網站上工作，可以重構整個思維；或者我在一個可以發佈新的主要版本的庫上工作。是的，我可能第一個錯了，但改變起來並不難……而你們正在處理的東西在這種意義上很難改變。
好吧，我們很難更改。對於Go 1，我們刻意寫下我們保證不做任何更改。這對於語言的成功至關重要，因爲它使企業能夠相信我們正在做的事情以及依賴我們的事情不會破壞他們的工作……而這使得進行更改變得更加困難。我認爲很多人不欣賞我們對合同的熱情。儘管這是一個已有十年曆史的項目，但我們並未違反人們的計劃。這是一個令人難以置信的負擔，但對於使我們到達現在的位置至關重要。
那就對了。一旦有了1.0，幾乎就是公司開始使用它的時候。以前，這就像“很有趣，很酷……”，那也是我們停止進行任何重大更改的時候。
我們並沒有多說一件事-即使在2009年發佈該語言之後，我們仍然對該語言進行了相當多的更改。例如，如果我沒記錯的話，分號在我們的初始版本中仍然存在。我們可以進行很多更改，然後在1.0之後停止。
在1.0之後，您將無法進行這些更改。他們有時仍在挑戰以做出那些自以爲是的改變嗎？我可以舉一個例子，就是有些人不喜歡這樣的事實，當您有未使用的變量時，它會給您帶來編譯時錯誤。我懷疑如果您以後要添加，那就是這種類型，因爲很難，因爲有人會想：“您爲什麼這樣做？您正在破壞我的代碼。”因此很明顯，這將破壞1.0的承諾。但是在此之前，您獲得了開源社區的支持，還是相對容易做到？
我認爲我們沒有太多反饋。除了可能的bug，我認爲我們沒有-首先，我們沒有適當的流程來處理功能請求或類似的事情。那時我們還沒有真正看到類似的事情。當然，在1.0之後，我們不能再進行此類更改，只是因爲它會破壞兼容性，而這是我們不想做的事情。我們仍然不這樣做。
Go的某些功能對人們的成功至關重要，這是人們所不喜歡的，我們對此非常直言不諱。我認爲您提到的一個，其中一個是未使用變量的編譯錯誤。這很煩人-您忘記刪除未使用的變量，程序就會編譯。但是對於我們來說，這只是我們要講的故事的一部分，這就是使一種語言能夠儘可能保證高質量的代碼，即使我們不能阻止您編寫不良代碼……但是我們可以確保事情不會拖延，這會使您的構建速度變慢，或者代碼難以維護。
[ 00：31：41.28 ]我認爲真正使人發狂的一個原因是您不允許導入不使用的庫。這對我們至關重要，因爲我們花了很多時間來進行大量二進制文件的緩慢構建，確保您程序的依賴項完全是您所需要的，而不再是其他依賴項。這對我們至關重要，但對於很多人來說，每次您進行編輯並刪除打印語句或類似內容時，編譯器都會說“您沒有使用此庫。我不會再建立你了。”
然後，布拉德（Brad）編寫goimports了一個名爲的東西，這是gofmt爲您管理進口商品的一種變體，幾乎消除了該抱怨。通常，自動化可以消除很多煩惱。
導入的要點–當然，編譯器可以很容易地弄清楚是否使用了導入，但要點是您實際上看到自己在依賴其他內容，並且在視覺上得到了提醒現在，您要添加一個新的依賴項。
這是一個事後偏見的問題，但是您是否預見了10-12年後的軟件重用情況？
沒有。
所以這只是一種幸運的猜測，還是直覺？
嗯，這並不是軟件本身的重用，而是經驗，尤其是在Google上，我們擁有一個龐大的環境，可以在您的程序中使用成千上萬個潛在的庫，而且我們已經看到了一些清理工作，有時，二進制文件的大小減少了40％或50％，因爲從樹中修剪了真正未使用的依賴項。因此，我們知道依賴性控制是保持構建整潔的重要組成部分，而該語言實際上可以爲您提供幫助。在少數地方，一種語言可以通過強制執行某些規則來使軟件變得更好，這很容易。這很容易，值得。
但是人們對此頗有好感，因爲編譯器會因爲看起來像是天真的錯誤而大喊大叫……但是我們希望編譯器只接受乾淨的程序。就像我說的那樣，社區–我們收到很多關於它的郵件，但都在抱怨，但是Brad只是通過製作一個可以完全解決該問題的工具來解決了這一問題，這很棒。
這是諸如此類之類的工具背後的動機gofmt，還是您只是試圖從根本上強迫人們使用符合某些標準的代碼？因爲我知道您看到的所有其他語言，所以每個人對於Prettier，JSON或他們所做的任何事情都有不同的設置-他們有一些隨機的“這就是我們使用的”設置，因此無論您走到哪裏，都變化。
gofmt作爲可讀性審覈者，我的沮喪感有所增加。大多數公司，當然還有Google，都有一個我們檢查彼此代碼的過程，以便對所有簽入的代碼進行同行評審……而且，大多數評審遵循樣式指南。而且，如果您在該樣式指南中查找了諸如C或C ++之類的語言，則許多樣式指南中都充滿了“您應在此處縮進很多，並且需要在其中留有空白”等等。與工程或您編寫的代碼實際上沒有或沒有多大關係的事情，只會花費很多時間。所以我覺得這是我們應該完全自動化的事情。數以千計的工程師浪費了很多時間，基本上是告訴別人“您是否需要在此處放置空白”，或者遵循某人編寫的某些樣式指南。
格式化程序是在過去編寫的，這不是第一次，但是我建議我們應該這樣做，而且我想這樣做。而且Rob基本上說：“您知道，表明它可以完成。”花了一段時間，毫無疑問；它花了幾年時間纔到達現在的位置，而且顯然還不完美，但是人們已經愛上了它gofmt，儘管他們gofmt有時討厭自己的風格。
[ 00：35：57.00 ]我認爲gofmt是在一兩天內就開始了。我們知道我們想執行它。
是的，是的。
並完全感謝Robert的成功，因爲這是一個真正的工程挑戰。但是我相信Go是通過這樣的外部工具強制進行格式設置的第一語言。還有一些語言在語法上的不同。但是Go是第一個說“您在程序上運行此工具，然後我們強制採用這種格式的工具”。它影響了社區的其他成員。其他語言得到了支持。現在有一種Java格式化程序被廣泛使用，Rust有一個，C ++通過Clang有一個，而且我認爲越來越多的人正在理解它的價值。
從我的角度來看，該項目中發生的一件非常有趣的事情gofmt是很棒的，最終被所有人採用，但是它提供了一種我們沒有想到的工具。因爲事實證明，如果有的話，gofmt主程序基本上就是一個環繞着進行打印的庫的主程序……並且不久之後，我們意識到，如果您有一個可以格式化代碼的庫，則可以編寫可在軟件並自動進行重構，然後生成完全有效的，格式整齊的輸出……這使許多動態編輯工具可以直接在代碼上運行，但仍可以生成可簽入的代碼。我們有一些。
Go 1.0的啓動-庫中有大量更改，語言的一些細節也有所變化，Russ編寫了一個程序，稱爲gofix，其中包含這些小插件模塊，這些小插件模塊實現了語言的更新或庫使用的更新……但是有關該過程的令人驚訝的事情是，我們大約每週都會發佈一個很小的版本，並且通常帶有一個Gofix模塊，如果您是該語言的用戶，則可以更新Go安裝，然後在所有代碼上運行Gofix，它將完全自動將其更新。因此，我們帶動了整個社區。我們不是通過擁有功能或“如果……那樣”來解決兼容性問題，而是創建了一個工具，該工具可以使每個人隨身攜帶其軟件，並隨時瞭解正在發生的變化。而這是通過使其成爲可能的gofmt，但是我不相信我們直到真正發生時才意識到這一點。
是的，我認爲這是– Russ開始的。
是的 我們對進行了難以置信gofix的大規模重構，尤其是在Google樹中。這是一個了不起的發現，我認爲完全是出乎意料的。
您談論gofmt它及其意想不到的後果……告訴我您如何看待Go對開源世界的影響。
我絕對認爲，今天-也許不是專門針對開放源代碼的世界，而是說一些較新的語言...如果您現在要推出一種新的語言或系統，則可能想發送某種格式程序。它幾乎已成爲標準要求。我認爲一切統一格式的事實可能會在每個人都希望這樣做的意義上影響開源世界，因爲它實際上具有一些積極的副作用，例如當您與變更合併時，您可以減少人爲變更的數量只是由於格式上的差異……所以這裏有一些協同效應。
另外，所有代碼看起來都一樣，聽起來很奇怪，但是–沒有兩個C程序看起來相似，但是每個Go程序看起來都一樣。我認爲這增加了您使用語言，與其他人一起工作，理解它的難易程度……太好了。
[ 00：39：58.22 ]我們要做的另一件事是我們–語言不是第一語言，但在嚴格地作爲UTF8源代碼方面，它是最能說明問題的。我們剛剛對所有這些可笑的其他編碼說了再見。我不會因爲改變UTF8在世界上的重要性而歸功於Go，但我認爲Go之後出現的幾乎所有語言都對UTF8輸入具有相同的規則。
我認爲這對我們也很重要-希望我們產生更大影響的是您首先編寫規範的想法。我認爲許多其他語言的後續工作可能會從中受益。我知道Rust僅在現在才獲得正式規格。就我所知，這本書正在進行中……而且我發現很奇怪，您將在不確切知道要實現的語言並將其編寫下來的情況下實現編譯器。
擁有規範的另一件事是，它使開箱即用的替代實現成爲可能……現在有很多Go編譯器。有一些使用Go to Javascript，有一個在GCC / Clang套件中，有一個LLVM Go，有一個我們自己爲Go項目運行的原始Go編譯器，所有這些都是基於規範的……而如果您沒有規範，而您所擁有的只是編譯器，限制了您可以學習的知識，以瞭解該語言的正確之處，該語言的錯誤之處，其他技術以及類似的東西。因此，我認爲制定規範並沒有得到應有的重視，但我希望如此。
我認爲這裏的區別在於，使用Go語言時，我們並沒有真正嘗試進行語言研究。我們試圖根據已久的實際語言設計和技術提出一個更簡單的工具，然後以更新，更現代和更好的方式將其打包。
許多更新的語言-當然，在我看來，Rust實際上正在進行語言研究，所以……有很多未知數。
是的，他們正在嘗試一種非常不同且非常聰明的方法，我希望它能夠成功……但是，是的，他們正在嘗試解決一個與我們試圖解決的問題截然不同的問題。我們還想到了什麼，認爲影響發生了？
我認爲我們對兼容性的立場對社區來說也意義重大。我們之前已經提到過，但是我認爲其他人可以通過認真思考他們如何以我們所擁有的精度來實現向前和向後兼容而受益……因爲這對我們和我們的社區都產生了巨大的影響。毫無疑問，這會使某些事情變得更加困難。如果您有一個好主意，則不能僅僅實施它。如果發現錯誤，則無法修復...但是社區和所有軟件的穩定性對於Go生態系統的增長確實非常重要。
在過去的十年中，您對軟件行業和編程語言的發展感到驚訝嗎？
我認爲所有人都對開源如何成爲主流感到驚訝。我認爲GitHub在2007-2008年左右發佈時，大約在Go發生的同時，也發生了GitHub。…在GitHub之前，對於很多人來說，開源是非常利基的市場。但是現在企業軟件系統幾乎都使用了一些開源組件，我認爲行業改變這種工作方式已經是一個突然的改變。從網上獲取代碼不只是開源。整個過程，包括如何管理依賴項，如何進行更新，如何在分佈式環境中構建，使用Web上的Git和代碼審查工具以及所有類似的東西。所有這一切都是新的，我認爲開源社區爲現代軟件開發做出了巨大貢獻……
[ 00：44：10.07]但這不只是開源社區了；整個軟件領域現在都在使用這些工具……我認爲這完全是出乎意料和令人驚訝的，但是它也帶來了一些非常棘手的問題，例如依賴管理以及如何保持依賴的安全性和最新性。現在，典型的Node安裝將有大約一千個依賴關係，這簡直太瘋狂了……而且我認爲您無法自信地說可以信任不擁有的一千個依賴關係。您怎麼知道代碼是好的，安全的，健壯的，受保護的，正確的更新時間，錯誤的更新時間，錯誤已修復-所有這些問題都非常棘手。Go也已經擁有了。因爲它是其中的一部分，所以它從開源生態系統中獲取依賴關係。依賴樹的規模對於Go來說並不像在其他一些世界中那麼大，但是仍然很大。例如，它比C ++程序通常要大得多……而您如何知道自己擁有的是值得信賴的呢？
Go團隊在嘗試提高從網上抓取代碼的安全性和可靠性方面做了很多工作，但是……我認爲，這仍然是一個令所有人感到驚訝的問題。
讓我感到驚訝的一件事是Go問世後不久出現了多少種新語言。因爲在2007年左右，語言世界似乎有點停滯不前。有C ++，有Java，Javascript，但除此之外沒有太多。
蟒蛇。
當然是Python。是的，用途廣泛……然後Go出現後不久，到處都有許多不同的語言出現，我認爲這很有趣。我認爲少即是多的想法開始引起更多人的共鳴。我認爲這是一個積極的發展。
不是所有人。
不是所有人，是的。
[ 00：46：17.18 ]
我認爲編程語言生存的時間越長，就越需要克服複雜性或功能蠕變，對嗎？
正確。
因此，那些存在時間更長的應用程序必須嘗試–簡單化是還原性的，但是爲了使事情變得更簡單，他們必須編寫包裝器和超級包裝器，並且它們是累加器，這有點矛盾……所以我認爲這也是我們在編程語言發展史上所處位置的一種功能。
我認爲這是一個戰略問題。您可以選擇其他方式。還有其他語言。C ++就是其中之一，Perl可能包含了複雜性。我讚揚Bjarne Stroustrup（C ++的作者），因爲他給了用戶他們想要的一切。他們要求更多，並且他給了他們更多，結果他最終建立了一種語言，這種語言一直是而且仍然是全球軟件開發的關鍵部分。Google的核心仍然主要是C ++，我相信許多其他公司也是如此。
[ 00：48：13.07 ]那是我們採取的完全相反的策略，那就是鎖定它而不是改變它。爲了鎖定它，您必須相信自己的願景是有道理的，這是正確的要做的事。我並不是說這些方法中的任何一種都是更好的。它們只是完全不同的策略，兩者都可以起作用。這是您必須在系統中的某個時候做出的決定，您想採用哪種方式。
我發現令人驚訝的是，C ++在2009年變得更加複雜，而且可能仍然如此。而且，您是對的，如果您想保持向後兼容，即使您在此處和此處添加了一些小東西，隨着時間的流逝，語言當然也會不斷髮展。我個人希望繼續開發模塊，通過說如果您使用的是1.15版或類似的版本，您將不會有一些我們認爲已經過時的功能，或者也許是不合適的或設計得不好，相反，您可能會得到其他東西。因此，至少這是我的希望，也許我們可以遏制這種增長並保持增長的勢頭……但我們會看到的。
擁有工具也有幫助，因爲與gofix- 一樣，您可以想象有一個新的工具可以gofix幫助我們在前進的過程中清理外界的代碼庫……這是Robert所做的另一件事（與gofmt有關）；在標準庫中使用該語言的解析器和詞法分析器可以非常輕鬆地編寫工具。
來自開源社區的早期事情之一就是對IDE的要求。“ Go IDE在哪裏？我想要的Go專用編輯器在哪裏？”這從未發生過。我們沒有創建它。有很多……GoLand現在是特定於Go的，但實際上只是IntelliJ的一個版本。相反，我們擁有的是一個非常好的庫，用於分析Go程序並對其進行編輯，並且具有熟練的程序員（無論如何都不是專家）基於該庫編寫工具的能力。因此，我們沒有創建用於Go的IDE，而是創建了一個庫，該庫使編寫IDE的插件變得容易。因此發生的事情是所有IDE現在都很好地支持Go，但是我們從未編寫過Go IDE。這是另一個戰略問題。我認爲這不是故意的。我認爲這是又一次事故。我們有點想要一個Go IDE，但是從來沒有覺得我們是合適的人。但是，取而代之的是，它變得不必要了，因爲Go與其自身工具的集成非常有效。
那是另一回事–你提到卡門，我們做了什麼；我不爲此而感到自豪，我真的認爲Go並沒有全部開始，但這是一個生態系統的真正好例子，而不僅僅是一種語言……它帶有自己的構建工具，自己非常強大的庫。您可以直接用大約十行代碼編寫可用於生產環境的Web服務器。與依賴項管理的集成不同於人們今天想要的，但我認爲它從很早就開始了。現在，模塊的內容正在更直接地解決。但是，對於像這樣的編譯語言來說，隨語言一起提供語言工具是一個不尋常的步驟。我認爲Rust的貨運系統表明這確實是可行的方式。那是一個變化。
好吧，我們還剩下大約十分鐘的時間，我想談談Go的持久品質。我們將迎來十年並慶祝十年……下一個十年呢？您希望Go在第二個十年或歷史史上將走到哪裏？
[ 00：52：07.15 ]它已經超出了我想象的範圍，所以我不知道我對它前進的方向的想法……我永遠也夢想着它不會像現在那樣脫穎而出，成爲儘可能大和主流。它不是世界上排名第一的語言，它永遠不會-並非意味着-坦白說，它的成功一直令我們感到震驚。
是的，我完全同意。我認爲我們不可能預見到這一點。我認爲只有時間才能說明十年後的發展趨勢。
您認爲它將經受住時間的考驗嗎？
我認爲這取決於那段時間。我們已經有十年了-從一開始的確是十二年-而且看起來還不錯。但是事情可以改變。我認爲我們對社區的方法有了很大改進。我們的社區正在成長，這個社區感覺像我們是一個熱情的社區。我認爲其中很多可以追溯到安德魯·格朗德（Andrew Gerrand）的所有工作，他在這方面做了大量的社區工作，並制定了社區行爲準則等。我認爲這是一個重要方面。然後，當然還有語言，庫和其他東西。
Russ在模塊方面的工作是巨大的進步。這就是我們最初以某種方式錯過的東西；我們沒有真正很好地研究供應商和依賴性問題。我認爲這是業界希望看到的東西，他們對此非常滿意。
我認爲，這是我們在過去幾年中朝着正確正確方向邁出的一些重大步驟。而且我認爲房間裏有個大大象，這是通用功能……而且我認爲我們正在放大某些內容，但是我不說最後一句話，也不知道我們是否要去那裏， 當然。
無論Go作爲語言和生態系統的遺產如何，我認爲它所產生的影響將經受住時間的考驗。我認爲由於羅伯特（Robert）的緣故，gofmt現在幾乎已經接受了佈局代碼的大部分工作應該由工具而不是人來完成。我認爲，專注於制定正確的規範並考慮確保具有正確的功能非常重要。強迫UTF成爲語言規範，做很多我們之前提到的事情-它們會起作用。作爲標準流程的一部分，我們進行代碼審閱的方式-不僅是拉取請求，而且實際上我們還使用了一個不錯的工具套件進行了完整的審閱……這種事情。
我們已經與其他項目進行了交談。我們想知道我們的工作方式以及我們如何接受社區貢獻，有時他們會驚訝於我們首先查看它們，而不是先接受然後再清理。這只是一種態度。我們要確保進入系統的所有內容均達到最高質量。這種方法並不是普遍喜歡的，但效果很好，而且我認爲許多其他項目也已經學會了考慮項目的運行狀況，而不僅僅是功能集和獲得的用戶添加它們。
因此，我們的生態系統中的某些方面不一定具有開創性，但無論Go發生什麼，都會對未來系統的構建方式產生一定的影響。
[ 00：55：49.16 ] Go社區仍在不斷髮展，誰知道它會變得越來越大。正如我所說，我認爲這不會成爲有史以來的第一語言，甚至不會接近它。教育還沒有建立起灘頭堡的一個地方。我想看看。我認爲，除非在大學裏教授過，否則它永遠不會真正成爲主流語言。而且，這幾乎還沒有發生。有一點點，但還不夠。既然Python幾乎已經成爲除系統軟件以外的所有語言的事實語言，我認爲Python是您應該談論的未來語言。
嗯……真可惜，因爲我選了計算機科學，但我真的不喜歡它。我告訴大家這個故事。我只是希望自己擁有Go語言，因爲我確實覺得Go語言是一種我們可以完全重新考慮如何教授計算機科學的方法。
好吧，現在大多數科學軟件開發都是用Python完成的。沒關係，我對此沒有任何問題。但是正因爲如此，並且由於許多通用軟件教育都是使用Python進行的，因此很難將如此清晰明瞭且與機器接近的語言納入標準課程。我沒有抱怨，這就是事實。
我很想看到Go用於教學。不一定是入門語言，而是大學課程的一部分。但是到目前爲止，它實際上僅在一些專業課程中才發生。
我認爲大學的問題之一是，他們幾乎具有這樣的授權：要教學生行業需要什麼，而這並不是我上學時要做的。當我上學時（我在談論計算機科學），我們瞭解了技術和不同種類的語言以及不同的做事方式，這些不一定與當時的行業緊密相關。可能是COBOL或C。因此只要不改變，大學將很難真正拓寬視野並使用其他語言。
由於機器學習，Python現在特別受關注。Python使您可以輕鬆地連接本質上爲C的庫，它只是在頂層。
好吧，Jupyter Notebooks絕對是一件了不起的事，我希望我在學生時代就擁有過。
辛苦了！那將改變生活。好吧，喬恩，您對羅伯或羅伯特還有其他問題嗎？
我想我想問的是你們前面提到的，當您開源時，您還沒有爲此做好充分的準備。參與其中就像是一個學習階段。我想至少對於我來說，我知道我發佈的第一個開源項目，我做的最大問題可能與你們所做的相反，我基本上把一切都扔給了我，因爲我很興奮人們足夠關心要做某事，而只是想把它全部拿走……大概三個月後，我正在研究它並試圖對其進行維護，我感到“這真的很難維護”，因爲我犯了一個錯誤，那就是僅僅使用所有功能。我所能做的一切 你們的心態相反。
好吧，我認爲行爲準則業務雖然對某些人很有爭議，但卻是建立社區的重要組成部分。我認爲人們需要了解這是一個相互尊重的社區，不受歡迎的巨魔……尤其是在今天，大聲說出來似乎更爲重要，但我認爲這是建立健康社區的重要組成部分。
[ 00：59：53.14 ]從技術角度來看-是的，您必須密切注意獎金。如果讓不好的功能或太多的功能不受控制地進入，最終將導致很難維護的軟件。但是，當社區正在推動您不滿意的事情並確保確定時，需要大量的工作來使社區參與，並且您將把人們趕走。有人會向您發送請求請求，然後您說“您知道什麼，我不想要這個”，然後您會解釋原因，做好解釋，但是他們可能仍然覺得您錯了，並且被冒犯並帶他們的玩具回家。因此，您必須準備好儘可能愉快的同時說不，這將是非常困難的。
是的，我認爲這就是重點。您基本上想要堅定但禮貌，並且想要確保人們覺得您在聽他們的話，基本上驗證了他們在說什麼，但這並不意味着您必須接受每一個建議實現其他人想要的。我認爲這裏有一點。
但這就是說，會有很多東西進來，這很棒，但是在您接受它之前，需要先對其進行精煉和拋光。而且，如果您有禮貌地交往，並解釋您想改變的地方，那麼如果他們的東西落空，您將贏得一個盟友，這將使另一個願意幫助的人在系統上變得更好。
順便說一句，如果您可以說服某人爲什麼某些功能請求可能不是一個好主意，並且您可以說服他們，那麼您也有一個盟友，因爲他們意識到“哦，好吧，這些人是真的在考慮這些東西。”
您想爲新一代的地鼠提供任何建議嗎，在我們關閉之前，你們兩個之間還有什麼遺言嗎？
好好享受！我們早期使用的一個詞-我們想再次使編程變得有趣...因爲它已經成爲了-當然對於我正在研究的某些東西，可能還有Robert-只是一個口號。45分鐘的構建和單行編輯會導致整個系統發生重大變化。我們想要的東西要輕一些，我想確保我們記得編程是一件有趣的事情。
現在在雲開發環境中工作-有很多活動部件。那裏又變得複雜了。確保您專注於正確的更改，以及正確的處理方式，以使操作靈活，適應性強並且有趣。多不一定總是最好的。有時候，精打細算可能是前進的更好方法。
是的，我認爲保持開放的態度並在框外進行思考很重要。僅僅因爲某件事已經以某種方式完成了五年，並不意味着這是正確的方式。我想回想一下我以前講過的關於語言和教育的內容……今天，大多數人在參加正規的計算機科學課程時可能已經看到一種或兩種語言。Java可能是其中之一，Python可能是其中之一，但是它們屬於同一類語言。
過去很少有人見過真正不同的語言，例如Lisp，Scheme或Smalltalk，那裏的事物（或功能語言）與主流語言完全不同。這些語言爲您提供了可能會改變您的觀點的不同想法和思考方式。但最重要的是，我想我們要確保儘可能降低複雜性。我們確實必須使它儘可能簡單……聽起來很容易。每個人對簡單事物都有不同的想法，但這確實很難。您想在所有情況下都儘可能簡單，因爲它會在某些時候咬住您。
聽起來像是新的KISS首字母縮略詞。這很棒。感謝Robert和Rob，今天與我們在一起，慶祝GoTime的第100集。我們真的感到很榮幸，很高興有您。
感謝您的光臨。
謝謝。