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 的初创公司成功上市或被收购。这些都是间接的:编程语言的选择无疑对公司的成功是一个非常小的因素。但这将是另一种方式来表明 Go 可以成为一个成功的软件系统的一部分。

您是否(更)考虑过动态加载 Go 包或对象以及它如何在 Go 中实现的可能性? 我认为这可以实现一些真正有趣且富有表现力的结构, 特别是与接口结合使用。

Rob: 这是一个活跃的讨论话题。我们很欣赏这个概念的强大之处,并希望我们能尽快找到实现它的方法。在设计方法上存在严峻的挑战,并且需要使其能够跨平台工作。

之前有人讨论过将一些一流的 database/sql 驱动程序集中到一个更中心的位置。 但有些人对此持强烈反对意见。 未来一年 database/sql 及其驱动程序的发展方向是什么?

Brad: 虽然我们可以为数据库驱动程序创建一个官方的子仓库(“go.db”),但我们担心这会不当的褒奖某些驱动程序。目前,我们仍然希望看到不同驱动程序之间健康的竞争。 SQLDrivers 维基页面列出了一些不错的选择。

database/sql 包在一段时间内没有得到太多关注,主要是因为缺乏驱动程序。 现在驱动程序已经存在,该包的使用率正在增加,并且也报告(并修复)了正确性和性能 bug。 修复工作将继续进行,但没有计划对 database/sql 接口进行重大更改。 可能会根据需要进行一些小的扩展,以提高性能或帮助某些驱动程序。

版本控制的现状如何? 从 GitHub 导入代码是 Go 团队推荐的最佳实践吗? 当我们将依赖于 GitHub 仓库的代码发布出去,并且被依赖仓库的 API 发生变化时,会发生什么?

Ian: 这在邮件列表中经常被讨论。我们内部的做法是获取导入代码的快照,并时不时地更新该快照。这样,如果 API 发生变化,我们的代码库就不会意外中断。但我们理解这种方法对于那些自己提供库的人来说并不太好用。我们乐于接受这方面的良好建议。请记住,这是围绕语言的工具方面,而不是语言本身;需要在此解决的问题是在工具中,而不是在语言中。

Go 与图形用户界面(GUI)呢?

Rob: 这是我最关心的问题。Newsqueak,一个非常早期的前身语言,就是专门为编写图形程序(我们过去称之为应用)而设计的。现在的形势已经发生了很大变化,但我认为 Go 的并发模型在交互式图形领域大有可为。

Andrew: 有许多 现有的图形库绑定,以及一些 Go 特定的项目。其中一个更有前途的项目是 go.uik,但它仍处于早期阶段。我认为,要创建一个很棒的、专用的 Go UI 工具包来编写原生应用程序(考虑通过接收通道中的事件来处理用户事件),潜力巨大,但开发一个生产质量的包是一项重大的工程。我毫不怀疑它最终会实现。

与此同时,Web 是用户界面最广泛可用的平台。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: 这非常令人兴奋。我相信我们中的一些人会参加。

下一篇文章:Go 与 Google Cloud Platform
上一篇文章:Go 高级并发模式
博客索引