卡门（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集。我们真的感到很荣幸，很高兴有您。
感谢您的光临。
谢谢。