开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
官方发表关于 Go 2 的博客声明 - 技术翻译 - 开源中国社区

官方发表关于 Go 2 的博客声明 【已翻译100%】

英文原文:Toward Go 2
标签: <无>
oschina 推荐于 1个月前 (共 28 段, 翻译完成于 09-13) 评论 0
收藏  
0
推荐标签: 待读

简介

[这是在 Gophercon 2017 上发表的演讲文稿,在讨论并规划 Go 2 时,寻求整个 Go 社区的帮助。当视频可访问时,我们将添加一个链接。]

2007年9月25日,Rob Pike、Robert Griesemer 和 Ken Thompson 在几天之内一直在讨论一种新的编程语言,Rob 建议命名为“Go”。

次年,Ian Lance Taylor 和我加入了团队,我们五个人一起组建了两个编译器和一个标准库,这使得其在2009年11月10日开源版本的发布

Tocy
 翻译得不错哦!

在接下来的两年中,在新的Go开源社区的帮助下,我们尝试了大大小小的变化,改进了 Go,并于2011年10月5日提出了 Go 1 计划


在 Go 社区的更多帮助下,我们修改并实施了该计划,并最终于2012年3月28日发布了 Go 1


Go 1 的发布标志着将近五年努力的创造巅峰,将我们的取的名字和一些想法转换成了稳定的生产语言。它也标志着从变化到稳定的转型。

在 Go 1 的几年中,我们改变了 Go,几乎每周都有重写。我们了解到,这使得 Go 不再适合在生产环境中使用,程序无法每周重写以跟上语言变化。Go 1 发布的博客文章上说道,驱这一切都是为创建可靠的产品,项目和出版物(博客,教程,会议谈话和书籍)提供稳定的基础,让用户确信他们的程序将在今后几年内继续编译和运行而无需更改。

亚林瓜子
 翻译得不错哦!

在 Go 1 发布后,我们知道我们需要花时间在生产环境中使用 Go,因为 Go 就是为生产环境而设计的。我们明确地从制造语言变化转移到在自己的项目中使用 Go 以及改进其实现:我们把 Go 移植到许多新系统,我们重写了几乎每个于性能至关重要的代码片段,以使 Go 运行得更为高效,并且我们增添了关键工具如 竞争检测器

迄今我们有五年使用 Go 构建产品级高质大型系统的经验。我们已经意识到什么可行,什么不可行。在 Go 的进化和成长之路上,现在该是开始下一步去计划 Go 的未来的时候。今天我在这里询问 Go 社区的各位,你们是否在 GopherCon 的观众席上,或在视频上观看,或在今天晚些时候阅读 Go 博客,以便与我们一道去计划和实现 Go 2。

圣洁之子
 翻译得不错哦!

在接下来的谈话中,我会解释我们对 Go 2 的目标、我们的约束和局限、写作有关我们使用 Go 的经验的重要性(特别是涉及到我们可能正设法去解决的问题)、各种可能的解决方案、我们将如何交付 Go 2,以及大家如何可以发挥助力。

目标

今天我们对 Go 仍持有与 2007 年相同的目标。我们想要在两个不同的层面上使程序员更为有效:生产层面,特别是与许多其他服务器交互的并发系统,今日之云软件即为例证,以及开发层面,特别是许多软件工程师仅在其上松散协作的大型代码库,今日之现代开源开发即为例证。

圣洁之子
 翻译得不错哦!

这两种规模出现在各种规模的企业。甚至五人的初创公司也可能使用其他大公司提供的基于云的大型 API 服务,并且更多是使用开源软件而不是他们自己编写的软件。生产规模和开发规模在初创公司和在谷歌一样重要。

我们对 Go 2 的目标是修正 Go 无法适应的最重要的那些方面。

(关于这些目标的更多内容, 请参阅 Rob Pike的 2012 文章 “Go 在 Google: 服务于软件工程的语言设计” 以及我在 GopherCon 2015 的发言 “Go,开源,社区”)

圣洁之子
 翻译得不错哦!

约束

对 Go 的目标从一开始就没有改变过,但是对Go的约束确实有改变。最重要的约束就是现有的 Go 用法。我们估计全球至少有 50 万 Go 开发人员,这意味着有数百万 Go 的源文件以及至少十亿行 Go 代码。那些程序员和那些源代码代表着 Go 的成功,但它们也是对 Go 2 的主要约束。

Go 2 必须带着所有那些开发人员。我们必须让他们改掉旧习惯,学习新习惯,只有当回报甚巨的时候。例如,在 Go 1 之前,错误类型的实现方法是命名为 String。在 Go 1,我们重命名为 Error,以便把能够自我格式化的错误类型与其他类型区分开来。有一天我在实现一个错误类型,不假思索地,我把它的方法命名为 String 而不是 Error,这当然无法编译通过。五年之后我仍然没有完全改掉这个旧习惯。那种澄清命名是在 Go 1 中做出的一个重要的改变,但对 Go 2 来说,如果没有一个很好的理由,那样的改变将是破坏性的。

圣洁之子
 翻译得不错哦!

Go 2还必须携带所有现有的Go 1源代码。我们不能分裂Go生态圈。在Go 2中导入Go 1编写的包,反之亦然的混合程序必须在多年的过渡期间毫不费力地工作。我们必须弄清楚如何做到这一点;自动化工具发挥了一定作用。

为了尽量减少干扰,每次更改都需要仔细思考、规划和加工,这反过来限制了我们可以做出的更改次数。也许我们可以做两三个,肯定不会超过五个。

我不关心次要的变更,例如允许使用更多语言的标识符或添加二进制整数文字。这些小的变化也很重要,但是更容易得到正确的结果。我今天专注于可能的重大变化,例如对错误处理的额外支持,或引入不可变或只读值,或添加某种形式的泛型或其他尚未建议的重要主题。我们所能做的只有这些重大变化。 我们必须仔细选择。

总长
 翻译得不错哦!

工作流程

这就产生了一个重要的问题:Go语言开发的工作流程应该是怎样的呢?

在Go开发的早期,只有我们5个人的时候,我们在一个紧挨着的用玻璃隔开的公共办公室办公,这样很容易把大家聚到一起讨论问题,然后再回到各自工位去实现解决方案。如果在开发过程中遇到问题,又很容易地把大家再次召回。Rob和Robert的办公室有一个小沙发和白板,因此常常我们其中一个进去开始在白板上写一些样例代码,在此期间其它人手头的工作也可找到一个合适的暂停点,然后大家就可以坐下来开始讨论问题了。这种较少成员的协作方式显然不适用于当前的Go团队。

xiaoaiwhc1
 翻译得不错哦!

Go 开源代码发布以来的一部分工作已经将我们的非正式流程移植到更正式的邮件列表和 issue 跟踪器以及超过50万用户上,但我们未曾明确描述过我们的整体流程。或许我们根本没有想过这一点。现在回想起来,以下是我们在 Go 上的工作的基本概况,这是自第一个原型运行以来我们一直在遵循的流程。

  • Step 1:使用 Go,并积累使用经验。

  • Step 2:识别 Go 中可能需要解决的问题,并将其阐明,向其他人解释,将其记录下来。

  • Step 3:提出解决这个问题的方案,与他人讨论,并根据讨论修改解决方案。

  • Step 4:实现该解决方案,对其进行评估,并根据该评估进行优化。

  • Step 5:移植解决方案,将其添加到语言、库或人们日常使用的工具集中。

Tocy
 翻译得不错哦!

同一个人不需要为了特定的改动经历上述所有这些步骤。事实上,通常许多人在任何给定的步骤上进行协作,并且可能会提出许多解决方案来解决单个问题。此外,在某个时候,我们可能不想就某个特定思路展开进一步讨论,而选择回到早期的某个步骤。

我们不曾对整个过程做过深入讨论,但我们已经解释了其中的一部分。在 2012 年,当我们发布 Go 1 时,声称是时候使用 Go 了,我们不会再做出变更,我们当时解释过 Step 1。在 2015 年,当我们介绍 Go 改动的提案流程时,我们当时解释了 Step 3/4/5,但是我们从来没有详细介绍过 Step 2,所以现在我想介绍下。

(关于 Go 1 的发展和语言变化的转变的更多信息,请参阅 Rob Pike 和 Andrew Gerrand 在 OSCON 2012 的演讲“Go 1 之路”。有关提案流程的更多信息,请参阅 Andrew Gerrand 在 GopherCon 2015 上的演讲“Go 的形成“和 “提案流程文档”。)

Tocy
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(0)
Ctrl/CMD+Enter

暂无网友评论
顶部