Go Blog 中文翻译与 Go 核心成员对话
2013 年 6 月 6 日
在 Google I/O 2013 大会上, Go 团队的几位成员主持了 "Fireside chat". Robert Griesemer，Rob Pike，David Symonds，Andrew Gerrand，Ian Lance Taylor，Sameer Ajmani，Brad Fitzpatrick 和 Nigel Tao 接受了来自听众和世界各地有关 Go 项目各个方面的问题.
去年, 我们还在 I/O 大会上举办了类似的会议: 遇见 Go 团队.
Google 主持人提出的问题比我们在短短 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 的大量使用. 另一个将是进行大规模 IPO 或收购主要使用 Go 的初创公司. 它们都是间接的: 显然, 编程语言的选择对公司的成功至关重要. 但这是表明 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 工具包具有很大的潜力 (考虑通过从渠道接收来处理用户事件), 但是开发生产质量的软件包是一项艰巨的任务. 我毫不怀疑会及时到来的.
同时, Web 是用户界面使用最广泛的平台. Go 仅在后端为构建 Web 应用程序提供了强大的支持.
在邮件列表中 Adam Langley 表示 TLS 代码尚未 由外部团体审查, 因此不应该在生产中使用. 是否计划对代码进行审查? 并发 TLS 非常好.
Adam: 众所周知, 密码术很容易以微妙而令人惊讶的方式破坏, 我只是人类. 我觉得我不能保证 Go 的 TLS 代码是完美无缺的, 并且我也不想歪曲它.
在一些地方, 已知该代码存在侧通道问题: RSA 代码是看不见的, 但不是固定时间的, 除了 P-224 以外的椭圆曲线不是固定时间的, Lucky13 攻击可能起作用. 我希望通过固定时间的 P-256 实现和 AES-GCM 解决 Go 1.2 的后两个问题.
没有人上前对 TLS 进行审查, 但是我还没有调查我们是否可以让 Matasano 或类似公司来做. 这取决于 Google 是否愿意为其提供资金.
您如何看待关于 GopherCon 2014? 团队中的任何人都打算参加吗?
本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
关于 LearnKu
粤公网安备 44030502004330号
推荐文章：