Go 博客

与 Go 团队的对话

2013 年 6 月 6 日

在 2013 年的 Google I/O 大会上，Go 团队的几位成员举办了“炉边谈话”。Robert Griesemer、Rob Pike、David Symonds、Andrew Gerrand、Ian Lance Taylor、Sameer Ajmani、Brad Fitzpatrick 和 Nigel Tao 回答了来自观众和世界各地人们关于 Go 项目各个方面的提问。

我们去年在 I/O 大会上也举办了类似的活动：认识 Go 团队.

来自 Google Moderator 的问题远远多于我们在短短 40 分钟的活动中所能回答的。在这里，我们回答了在直播活动中错过的部分问题。

gc 工具链的链接速度（以及内存使用情况）是一个已知问题。 在 1.2 周期中是否计划解决此问题？

Rob： 是的。我们一直在思考如何提高工具的性能，以及语言和库的性能。

我很高兴看到 Go 的普及速度如此之快。 您能谈谈您在与 Google 内部和外部的其他开发人员合作时遇到的反应吗？是否还存在重大阻碍？

Robert： 许多认真尝试过 Go 的开发人员都对它感到满意。他们中的许多人报告说，代码库更小、更易读，因此可维护性更高：从 C++ 转型过来的开发人员通常会看到代码规模减少 50% 或更多。从 Python 转型到 Go 的开发人员总是会对性能提升感到满意。常见的抱怨是语言中存在一些小的不一致（我们可能在某个时候会解决其中一些）。令我惊讶的是，几乎没有人抱怨缺乏泛型。

Go 何时将成为 Android 开发的一流语言？

Andrew： 这将非常棒，但我们还没有什么可以宣布。

是否有 Go 下一个版本的路线图？

Andrew： 我们没有明确的功能路线图。贡献者倾向于根据自己的兴趣开展工作。开发的活跃领域包括 gc 和 gccgo 编译器、垃圾收集器和运行时，以及许多其他领域。我们预计大多数令人兴奋的新增功能将是针对工具的改进。您可以在golang-dev 邮件列表上找到设计讨论和代码审查。

至于时间表，我们确实有具体计划：我们预计将在 2013 年 12 月 1 日发布 Go 1.2。

您希望 Go 在外部被用于哪些方面？ 您认为 Go 在 Google 之外的采用中会取得哪些重大胜利？ 您认为 Go 在哪些领域有潜力产生重大影响？

Rob： Go 的部署取决于它的用户，而不是我们。我们很高兴看到它在任何有助于其发展的地方获得普及。它是在考虑服务器端软件的情况下设计的，并且正在那里显示出希望，但在许多其他领域也显示出优势，并且故事才刚刚开始。未来还会有很多惊喜。

Ian： 对于初创公司来说，使用 Go 更容易，因为他们没有需要使用的大量代码库。 因此，我认为 Go 未来有两个重大胜利。 一个是由 Google 以外现有的大型软件公司对 Go 进行大量使用。 另一个是主要使用 Go 的初创公司的重大 IPO 或收购。 这两点都是间接的：显然，编程语言的选择是公司成功的非常小的因素。但它将是另一种表明 Go 可以成为成功软件系统的一部分的方式。

您是否想过 (更多) 动态加载 Go 包或对象并使其在 Go 中运作的可能性？ 我认为这可以实现一些真正有趣且富有表现力的结构， 尤其是与接口结合使用。

Rob： 这是一个正在积极讨论的话题。我们很欣赏这个概念的强大之处，并希望我们能够尽快找到一种方法来实现它。在设计方法和需要使其可移植地工作方面存在严峻挑战。

之前曾讨论过将一些最佳 database/sql 驱动程序收集到更中心的位置。 但有些人对此有强烈的反对意见。 database/sql 及其驱动程序在未来一年将何去何从？

Brad： 虽然我们可以为数据库驱动程序创建一个官方子库（“go.db”），但我们担心这会过度推崇某些驱动程序。在这一点上，我们仍然希望看到不同驱动程序之间的良性竞争。在SQLDrivers Wiki 页面上列出了一些优秀的驱动程序。

由于缺乏驱动程序，database/sql 包在一段时间内没有得到太多关注。现在，由于驱动程序的存在，该包的使用率正在上升，并且现在正在报告（并修复）正确性和性能错误。修复工作将继续，但没有计划对 database/sql 接口进行重大更改。 根据性能或帮助某些驱动程序的需要，可能会进行一些小的扩展。

版本控制的现状如何？ 从 GitHub 导入一些代码是否属于 Go 团队推荐的最佳实践？ 当我们发布依赖于 GitHub 库的代码时， 如果依赖项的 API 发生更改会发生什么？

Ian： 这在邮件列表中经常被讨论。我们内部的做法是获取导入代码的快照，并定期更新该快照。这样一来，如果 API 发生更改，我们的代码库就不会意外中断。但我们明白，这种方法对于那些自己提供库的人来说并不奏效。我们欢迎这方面的良好建议。请记住，这是围绕语言的工具方面，而不是语言本身；解决此问题的关键在于工具，而不是语言。

Go 和图形用户界面如何？

Rob： 这与我的内心感受息息相关。Newsqueak，一种非常早期的前身语言，专门用于编写图形程序（这就是我们过去对应用程序的称呼）。情况已经发生了很大变化，但我认为 Go 的并发模型在交互式图形领域具有很多优势。

Andrew： 那里有很多现有的图形库绑定，以及一些 Go 特定的项目。其中比较有前景的一个是go.uik，但它仍然处于起步阶段。我认为 Go 特定的 UI 工具包在编写原生应用程序方面有着巨大的潜力（可以考虑通过从通道接收来处理用户事件），但开发一个生产级别的软件包是一项艰巨的任务。我相信总有一天会出现的。

同时，网络是用户界面最广泛可用的平台。Go 为构建 Web 应用程序提供了强大的支持，尽管这仅仅是在后端。

在邮件列表中，Adam Langley 已经声明 TLS 代码尚未 由外部组织审查，因此不应在生产中使用。 是否计划对代码进行审查？ 一个安全的并发 TLS 实现将非常棒。

Adam：密码学在微妙和令人惊讶的方式上很容易出错，而我只是个普通人。我不能保证 Go 的 TLS 代码没有错误，我不想误解它。

代码已知存在一些侧信道问题：RSA 代码经过了盲化处理，但不是恒定时间，除 P-224 以外的椭圆曲线不是恒定时间，并且 Lucky13 攻击可能有效。我希望在 Go 1.2 时间范围内通过恒定时间的 P-256 实现和 AES-GCM 解决后两个问题。

然而，还没有人自愿对 TLS 堆栈进行审查，我也没有调查过我们是否可以请 Matasano 或类似的组织进行审查。这取决于 Google 是否愿意为此提供资金。

您对GopherCon 2014有什么看法？ 团队中是否有人计划参加？

Andrew： 这非常令人兴奋。我相信我们中的一些人会去参加。