对Go团队的一次访谈

jopen 11年前

在Google I/O 2013上,几名Go团队的成员组织了一个名为“炉边谈话”的活动。Robert Griesemer, Rob Pike, David Symonds, Andrew Gerrand, Ian Lance Taylor, Sameer Ajmani, Brad Fitzpatrick, 与Nigel Tao一同回答了由现场观众与那些无缘当场的其他人提出的关于Go的多方面的特征的一些问题。

我们去年同样也组织过一个类似的活动:Meet the Go team.

当时我们收到了很多问题以至于我们无法在短短的四十分钟内一一回答。现在我们将会在这里对当时无法现场回答的一些问题做出解答。

连接速度(和内存的使用)对于GC的工具链来说是一个已知的问题。有没有计划在1.2期间搞定这个问题?

Rob:是的。我们总是在考虑改善工具的性能、语言支持和库的方法。

我已经很高兴的看到了,Go那么迅速就得到了显著的提高。你能谈谈,在同其他Google内外的开发者一起工作时,曾经得到的反馈吗?

Robert:许多开发者,在认真的使用了Go之后,都很高兴使用它。他们中许多人提出了一个小很多、更具可读性、如此易于维护的代码基:一个50%的代码缩减,而来自于C++的代码缩减更多是很常见的。从Python改用Go的开发者们,都很为获得的性能而高兴。典型的抱怨是关于语言中少量的不一致性的(在某一时刻,我们将解决他们当中的一些)。令我惊奇的是,几乎没有人抱怨缺少通用性。

Go语言会不会发展成为安卓开发的首选语言?

Andrew:非常棒的想法,但是目前我没有什么消息可以宣布。

关于Go语言的版本有没有路线图?

Andrew:我们没有关于功能的路线图。贡献者们倾向于在他们感兴趣的方面做工作。其中比较活跃的方面包括:gc和gccgo编译器,垃圾回收器和运行时支持(runtime),还有很多其它方面。而我们希望大部分令人激动的改进是对我们的工具(tools)进行改进。你可以在go语言的开发邮件列表找到关于设计的讨论和对代码审查。

至于时间线,我们确实有精确的计划:我们会在2013年的12月1号发布Go 1.2。

在外界的哪些领域使用Go是你们所希望看到的?在谷歌之外,如何使用Go会让你们认为是一个巨大的胜利?你们认为Go在哪些领域会有巨大的潜力?

Rob:在哪里部署Go取决于使用她的人,而不是我们。我们很乐意看到Go能在任何地方崭露头角。她一开始是被设计用于服务器端的软件开发,而且也确实在这方面展现出她的魅力。但是,她也在很多其它领域显现出了她的优势。整个故事其实才刚刚开始,还有很多的惊喜在等着我们。

Ian:Go很容易上手,因为新手不需要面对复杂难懂的代码基。所以,我们将看到在未来Go会有两个巨大的胜利:1.除谷歌之外,许多大型的软件公司会大量的采用Go语言。2.那些主要用Go的创业公司会有一个重要的IPO(首次公开募股)或者直接被收购。原因很直接:对编程语言的选择对于一个企业的成功是一个很小的因素。但是,这也以另外一种方式证明:Go会成为成功软件系统的一部分。

你们是否想过Go在动态加载方面(包或者目标文件)有非常大的潜力?是否考虑过在Go中如何实现动态加载?我认为如果实现动态加载会使一些有趣的构想成为可能,尤其是与接口相结合。

Rob:这也是一个经常被讨论的问题。我们能感受到动态加载的想法之强大,也希望我们不用花太长时间就能找到一个实现它的方法。毕竟在进行设计和跨平台的过程中肯定会有非常多的挑战。

之前有这样一个争论:收集一些database/sql驱动的最佳组合放到一个更加集中的地方。另外一些人则极力反对。明年database/sql会怎样发展呢?

Brad:当我们为数据库驱动创建一个子库("go.db")时,我们担心这样会过份的偏向特定的驱动。在这一点上,我始终希望能看到不同驱动之间的公平健康的竞争。在数据库驱动的wiki上列出了一些优秀的驱动。database/sql包在过去一段时间并没有获得太多的关注,主要是因为缺乏驱动。现在驱动有了,这个包的使用量也渐渐上升。更正和Bug也渐渐被反馈回来。我们会继续修复Bug,但是对于接口的变更暂时不在计划之内。可能会有一些协助某些驱动的提高性能的小扩展。

那版本的情况呢?从github中导入代码是Go团队推荐的最佳实践吗?万一我发布的代码中依赖的某个github库的API发生改变了呢?

Ian:嗯,这也是邮件列表中经常讨论的问题。我们自己的做法是导入代码,及时的更新快照。这样的话,当 API改变时我们的代码基就不会意外的崩溃。但是,我们明白这样的方法对于那些自己提供库的人不是很有效。我们开放的接纳关于此方面的建议。记住,这是一个关于Go语言的工具的问题,而不是语言本身。也就意味着:修复这个问题的地方是在工具里,而不是语言本身。

那么,关于Go和图形用户界面呢?

Rob:这也是我非常挂心的一个问题。Newsqueak, 被设计专门用来写图形程序(或者称之为app)的一个较早的语言。现在的局势发生了很多改变,但是我认为Go的并发模型在交互式图形方面会有非常大的优势。

Andrew:现在已经有很多对已有图形库的绑定,还有一些专为Go开发的图形库。其中前景最好的是go.uik,但是她现在还太年轻了。我认为专为Go语言编写的UI库在编写本地应用方面一定有非常大的潜力(想想:通过从一个channel接受消息来处理用户事件),但是开发一个工业级质量的库是一个非常艰巨且意义重大的事情。我相信不久之后就会有一个这样的库出现的。

与此同时,web平台是现在最广泛使用的用户界面,Go提供了对web应用的强大的支持,虽然只是在后端方面。

Adam Langley 在邮件列表中表示 TLS 代码还没有被外围组织审阅,这些不应该用在产品中。 有代码审阅的计划么?并发 TLS 拥有良好的安全实行是非常棒的。

Adam:加密在细微和奇诡之处容易弄得一团糟是出了名的,我只是一只人类。我不觉得 我可以保证 Go 的 TLS 代码将会如何如何完美,我不想歪曲这点。

代码中有很多地方有侧通道问题:RSA 代码会被蒙蔽但时间不定,P-224之外的椭圆曲线时间不恒定,Luck13 攻击可能会生效。我希望在 Go1.2 的时间表内,后面两个问题能够得到解决:一个时间恒定的 P-256 实现和 AES-GCM。

没有人进一步审阅 TLS 协议栈,而且,我没有调查我们是否能去 Matasano 或其它类似的地方。这取决于谷歌是否愿意资助。

你对 GopherCon 2014大会怎么看? 团队中的成员有参加的计划么?

Andrew::我很期待。我确定我们会出现的。