泛型 - Tony Bai

标签泛型下的文章

Go语言联合作者Rob Pike专访：Go确实已成为云基础架构的语言

五月 1, 2020
0 条评论

尽管看到Docker，Kubernetes和用Go编写的云计算的许多其他组件令人欣喜和重要，但也许并不奇怪。Go确实已经成为云基础架构的语言。- Rob Pike，Go编程语言的联合作者

本文翻译自《Rob Pike interview: “Go has indeed become the language of cloud infrastructure”》。

img{512x368}

简介

我们与Go编程语言之父Rob Pike(以下称Rob)谈谈跨越整整40年的职业生涯、过去10年来Go语言的变化，以及未来Go语言的演化方向。

专访

Evrone：您与今天的许多开发人员不同，您数十年前就在Bell Labs开始了您的职业生涯。以您的阅历和认知，您认为我们开发软件时最大变化是什么？

Rob：今天的软件规模(scale)更大。不仅是计算机和网络，还有程序本身。所有Unix版本6（大约1975年）的程序都可以顺利地安装在单个RK05磁盘包上，该磁盘包的存储量刚刚超过2MB，还为用户软件留出了很大的空间。那是一个很好的计算环境，或者至少在当时看起来是一个。当然，尽管我可以解释其中的大部分增长，但令人惊讶的是，也许并不是所有的增长都是合理的。

Evrone：鉴于“变革的阻力”和“兼容性的承诺”，您如何看待Go编程语言及其生态系统在未来十年的发展？您认为的该技术的最佳未来是什么呢？

Rob：尽管还不确定，但经过十多年的努力，一个看起来更像是针对参数多态性的设计，即我们俗称泛型(具有误导性)的东西将在未来一两年内问世。找到一个可以在现有语言中运行并且感觉好像属于它的设计是一个非常困难的问题，但是伊恩·泰勒（Ian Taylor）在该问题中投入了巨大的精力，看来现在已经找到了答案。我也非常渴望看到该设计会如何影响库、生态系统和社区的。

Evrone：随着“渐进类型”引入“动态类型”语言以及“类型推断”引入“静态类型”，两者之间的界限现在变得越来越模糊。您对现代编程语言的类型系统有何看法？

Rob：我非常喜欢静态类型，因为它带来了稳定性和安全性。

我也非常喜欢动态打类型，因为它带来的乐趣和轻巧的感觉。

我不喜欢类型驱动的编程、类型层次结构、类以及继承。尽管已经通过这些方式构建了许多非常成功的项目，但我认为这种方法将重要的决策过早地推到了设计阶段，而经验并没有影响到它。换句话说，我更喜欢组合而不是继承。

但是，我对那些喜欢使用继承来构造程序的人说：不必在意我的观点，请继续使用对你们有用的东西。

Evrone：有时候人们以奇怪的方式使用技术。例如，要从高级Python或Ruby代码生成高效的Go代码（是的，我们已经看到了！）多年来，您看到过最奇怪，最有创意或有趣的Go用法了吗？最让您惊讶的是什么？

Rob：最大的惊喜是当我们得知Go被用于编写恶意软件时(译注：手动允悲)。您无法控制谁将使用您的作品或他们将如何使用它。

Evrone：您设计和实现了许多文本编辑器。您如何看待Visual Studio Code？通过LSP之类的技术，“文本编辑器”和IDE之间的界限现在变得模糊了。您是否认为软件开发人员需要功能强大的IDE（如GoLand）或使用VSCode很好？

Rob：我来自IDE之前的时代。但是在项目的早期，有人谈到Go是否需要IDE才能成功。但是，团队中没有人拥有这方面的技能，因此我们没有尝试去创建一个(Go专属IDE)。但是，我们确实创建了用于解析和打印Go代码的核心库，这为各种编辑器和IDE快速创建了高质量的插件提供了极大的便利，这也算是一个偶然的成功。

最近，我们一直在努力为Go开发LSP服务器，该服务器称为gopls，支持该协议的任何编辑器或IDE均可使用该服务器，以改善使用该语言的体验。

也许是因为我们对使用简单的编辑器形式感到满意，所以我们确保大家无需背负沉重的编程环境搭建负担即可轻松地使用Go工作。但是，IDE当然可以提供帮助：我今天看到的大多数使用Go IDE或至少使用具有自定义Go支持的编辑器的开发人员都能从中获得很多价值。

使用哪种编辑器风格的问题取决于您的口味，并随您所用语言的文化而变化。

Evrone：软件开发人员倾向于给事物打标签，例如Dart是一种“前端语言”，而C是一种“系统底层语言”，等等。就目前的Go语言的功能集和用法，您现在如何称呼它？

Rob： Go是一种通用编程语言。编写您想要的任何内容，不必担心将语言或与此相关的任何其他技术固定到单个问题域。

Evrone：您个人还喜欢哪些其他现代编程语言？

Rob：Go的经验告诉我，人们喜欢对语言发表意见，这可能比我们领域中的几乎任何其他要素都要多。我当然也是这样做的。但是我对经常导致的消极情绪感到厌倦，所以现在我尽量避免评判那些事情。

在很少有新的语言问世并获得成功的一段时间之后，在过去的十多年中，语言设计才有了真正的复兴。很高兴看到这一点及其带来的创新。

Evrone：成为Google员工是如何帮助您开发和引导Go语言的？能够在Twitter上问“告诉我们您如何使用我们的语言”并获得全球最大公司的回应有多重要？它只是语言开发的一个不错的补充还是必不可少的一部分？Google如何为您提供帮助的？

Rob： Google非常支持Go项目，对此我深表感谢。当然，创建该语言是因为我们认为Google需要它。所谓的“云计算”需要一种具有对并发性和易于部署等方面良好支持的语言。但是Google并没有以任何重要方式指导该项目。它支持我们，让我们做我们认为最好的事情。

对于其他公司和其他用户，社区的投入对于理解项目的进展至关重要，我的意思是语言，编译器，工具，运行时，库，环境（所有这些）的发展。

Evrone：经过10年的Go开发以及对其使用方式的观察，您能说出该语言最大的设计成功和最大的失败是什么？分别是最强点和最弱点？

Rob：我要说两件事，一是技术问题，一是政治问题。

技术上是对并发计算的原生(first-class)支持。Go仅仅存在了十年左右，但是当它被开发时，“线程”和并发在编程社区中并未得到广泛认可。实际上，创建Go的主要原因是当时很难用C++进行并发计算。并发支持在发布后不久就很明显成为了该语言的一个主要吸引力，可以弥补一些人认为该语言其他部分的缺点。并发动了大家的神经。一旦人们开始使用并发功能，他们便开始探索有关该语言的其他内容，并发现那里(Go语言中)存在的东西超出了他们最初的想象。支持并发是（进入Go语言世界）的网关。

正如Cloudflare的John Graham-Cumming所说：“我为实现简单的并发而来，而为实现简单的组合而留下来”。

Go改变了有关如何对多核计算机进行编程的讨论。

Go语言在政治上的成功是坚定的执行了关于Go1兼容性的承诺。曾经我们和社区一旦使用Go几年，我们就有了很长的清单需要修复，但是变化是破坏性的。因此，我们仔细设计了更新程序，并使用了“go fix”命令来推动社区发展。完成这些后，我们不仅停了下来，而且还承诺会保持这种“停止”状态。这种稳定性 – 2012年编写的Go程序今天仍可以编译并完美运行 – 是促进增长的巨大推动力。公司可以放心使用我们，因为我们不会破坏其软件。在Go 1.0版本及其兼容性承诺出现之后，Go的采用率急剧上升。而且，从那以后，尽管我们有许多我们想改变的东西，但是我们不能破坏现有的程序，对此，我们感觉很好。

Evrone：您的工作与生活平衡如何？现在有很多关于“倦怠”的话题，这种流行病根本没有帮助。以你40年的阅历，您对新一代开发者有何提醒？

Rob：避免倦怠的最佳方法是在支持您的环境中做自己真正喜欢的事情。在整个职业生涯中，我一直很幸运，但是我意识到并不是每个人都如此幸运。如果您因工作而感到压力，则应随时休息或改变方向，尤其是在当前情况下。

Evrone：事后看来，许多技术的普及归功于使它们流行的所谓“杀手级应用”。您能为Go编程语言列举出这样的“杀手级应用程序”吗？您整体上对这种“杀手级应用程序”想法有何看法？

Rob：几年前，Danny Berkholz将Go称为“云基础架构的新兴语言”，这绝非偶然。Go是由Google的工作人员设计的，目的是使编写与Google相关的软件（特别是驻留在网络中的服务器）更容易。就是今天我们所说的“云”。（该设计的某些动机是在我2012年的Splash主题演讲: Go at Google: 软件工程服务中的语言设计。

因此，尽管看到用Go语言编写的Docker，Kubernetes和云计算的许多其他组件很令人高兴且很重要，但也许并不奇怪。Go确实已经成为云基础架构的语言。

Evrone：您觉得Go语言的竞争对手是谁？在哪个领域竞争？您对Rust的“无垃圾收集”构想和编译时保证有何看法？

Rob： Rust是一种有趣的语言，我很感兴趣地看着它的发展。除此之外，正如我上面所说，我没有意见。

Evrone：Go在GitHub上已达到7万颗星！您如何看待GitHub，Reddit，Twitter，离线和在线会议，网络研讨会等不同的社交活动对语言的影响？它们对语言的成功重要还是仅仅反映了语言的成功？

Rob：我们通过会议和社交媒体结识的人们一直是Go及其所有元素发展的关键部分。许多许多贡献者以积极的方式影响了开发，包括将Go移植到Windows和许多非x86架构上，工具和库的开发，对技术建议的深入讨论等等。

反过来，Go团队也与社区进行联系并积极讨论，提出问题并寻求帮助和指导。

我认为重要的一件事是，以一种声音与社区互动，以团队而非个人的身份说话。一致的消息更容易理解。

Evrone：成为一种流行的编程语言的作者如何改变了您的生活？

Rob：一个更正：我是合著者，而不是作者。肯·汤普森（Ken Thompson）和罗伯特·格里塞梅尔（Robert Griesemer）与我一起开始了这个项目，其他许多人也做出了巨大贡献。因此，请不要单把我列为“作者”。

为了回答您的问题，Go无疑提高了我的公众形象，并向我介绍了一个新的充满活力的社区，但是除此之外，它并没有太大的作用。我有很长的职业生涯，并取得了其他的成功（以及无数的失败）。

Evrone：想象一下，如果您有机会时光倒流并且给年轻时候的你提出一个建议（只有一个），如果是回到大约在您开始设计Go语言规范时，您会给您自己和您的同事提出什么建议？

Rob：很简单：忽略仇恨者(haters)。只倾听那些能理解和分享您目标的声音；他们是在乎Go的人。并非每个人都认同您在做的事情，这没关系。但是，那些致力于推进您想要做的事情的人可能会成为想法，能量和灵感的绝佳来源。

我们将永远感谢我们充满热情的社区。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.13中值得关注的几个变化

十月 27, 2019
0 条评论

2019年对于Go语言来说也是一个重要的年份，因为在2019年的11月10日，Go即将迎来其开源10周年的纪念日。在这个重要日子的前夕，在GopherCon 2019大会后，Go项目组在2019.9.4日发布了Go 1.13版本。

这是自2017年GopherCon大会上Russ Cox做“Toward Go 2″主题演讲以来Go项目发布的第四个版本（前三个分别是：go 1.10、go 1.11和go 1.12)。

Go2是这两年Go项目的核心主题。Go项目组也一直在摸索着向Go2演化的节奏和过程规范，并已经从Go 1.11版本起做出了实质性的动作：添加go module机制、错误处理优化、泛型讨论和多次草案的发布等。Russ Cox这段时间还在自己的博客上撰写了一系列有关Go proposal流程究竟该如何改进的探索性文章，这与当年vgo“放大招”前的节奏有些相似:)。

回归正题，我们来说Go 1.13这个版本。Go 1.13延续了对之前版本添加的Go2特性：Go module的优化；并且从该版本开始，Go项目组开启了Go2中呼声也很高的错误处理的优化。下面我们详细来看看Go 1.13中值得关注的几个变化。

1. 语言

Go 1.13中，Go语言规范有了一些小变化。

Go在设计伊始就和多数C-Family语言一样继承了C语言关于数字字面量(number literal)的语法形式，和1978年发布的K&R C一样，Go仅支持十进制、八进制、十六进制和十进制形式的浮点数的数字字面量形式，比如：

a := 53        //十进制

b := 0700      // 八进制，以"0"开头
c := 0xaabbcc  // 十六进制 以"0x"开头

c1 := 0Xddeeff // 十六进制 以"0X"开头

f1 := 10.24  // 十进制浮点数
f2 := 1.e+0  // 十进制浮点数
f3 := 31415.e-4 // 十进制浮点数

这些数字字面量语法应该说是够用的，但是和其他语言在进化过程中添加的其他数字字面量表达形式相比，又显得有些不足。于是Go设计者决定在Go 1.13版本中增加Go对数字字面量的表达能力，在这方面对Go语言做了如下补充：

增加二进制数字字面量，以0b或0B开头
在保留以”0″开头的八进制数字字面量形式的同时，增加以”0o”或”0O”开头的八进制数字字面量形式
增加十六进制形式的浮点数字面量，以0x或0X开头的、形式如0×123.86p+2的浮点数
为提升可读性，在数字字面量中增加数字分隔符”_”，分隔符可以用来分隔数字(起到分组提高可读性作用，比如每3个数字一组)，也可以用来分隔前缀与第一个数字。

a := 5_3_7
b := 0o700
b1 := 0O700
b2 := 0_700
b3 := 0o_700
c := 0b111
c1 := 0B111
c2 := 0b_111
f1 := 0x10.24p+3
f2 := 0x1.Fp+0
f3 := 0x31_415.p-4

注：截至目前，有些第三方工具依然无法识别数字字面量中的分隔符，会误报其为语法错误。

Go 1.13中关于语言规范方面的另一个变动点是取消了移位操作(>>的<<)的右操作数仅能是无符号数的限制，以前必须的强制到uint的转换现在不必要了：

var i int = 5

fmt.Println(2 << uint(i)) // before go 1.13
fmt.Println(2 << i)       // in go 1.13 and later version

不过值得注意的是：go 1.12版本在go.mod文件中增加了一个go version的指示字段，用于指示该module内源码所使用的 go版本。Go 1.13的发布文档强调了只有在go.mod中的go version指示字段为go 1.13(以及以后版本)时，上述的语言特性变更才会生效，否则就会报类似下面的错误：

// github.com/bigwhite/experiments/go1.13-examples/number_literal.go

$go run number_literal.go
# command-line-arguments
./number_literal.go:23:7: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:24:7: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:25:8: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:26:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:27:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:28:7: binary literals only supported as of -lang=go1.13
./number_literal.go:29:8: binary literals only supported as of -lang=go1.13
./number_literal.go:30:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:31:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: too many errors

// github.com/bigwhite/experiments/go1.13-examples/shift_with_signed_operand.go

$go run shift_with_signed_operand.go
# command-line-arguments
./shift_with_signed_operand.go:8:16: invalid operation: 2 << i (signed shift count type int, only supported as of -lang=go1.13)

当然，如果repo下没有go.mod或者单独在某个没有go.mod的目录下使用go 1.13编译器运行上面代码，则是无问题的。

2. Go module机制的继续优化以及行为变化

Go module自Go 1.11版本加入Go以来收到了Go社区的大量反馈，Go核心团队也针对这些反馈对Go module机制进行了持续地优化。在Go 1.13中，Go module的一些改变如下：

1) GO111MODULE=auto的行为变化

在Go 1.12版本中，GO111MODULE默认值为auto，在auto模式下，GOPATH/src下面的repo以及在GOPATH之外的repo依旧使用GOPATH mode，不使用go.mod来管理依赖；在Go 1.13中，module mode优先级提升，GO111MODULE的默认值依然为auto，但在这个auto下，无论是在GOPATH/src下还是GOPATH之外的repo中，只要目录下有go.mod，go编译器都会使用go module来管理依赖。

2) GOPROXY有默认初值并支持设置成多个代理的列表

之前版本中，GOPROXY这个环境环境变量默认值为空，go编译器都是直接与类似github.com这样的代码托管站点通信并获取相关依赖库的数据的；一些第三方GOPROXY服务发布后，迁移到go module的gopher们发现：大多数情况下通过proxy获取依赖包数据的速度要远高于直接从代码托管站点获取，因此GOPROXY总是会配置上一个值。Go核心团队也希望Go世界能有一个像nodejs那样的中心化的module仓库为大家提供服务，于是在Go 1.13中将https://proxy.golang.org作为GOPROXY环境变量的默认值之一，这也是Go官方提供的GOPROXY服务。

同时GOPROXY支持设置为多个proxy的列表(多个proxy之间采用逗号分隔)，Go编译器会按顺序尝试列表中的proxy以获取依赖包数据，但是当有proxy server服务不可达或者是返回的http状态码不是404也不是410时，go会终止数据获取。

Go 1.13中，GOPROXY的默认值为https://proxy.golang.org,direct。当官方代理返回404或410时，Go编译器会尝试直接连接依赖module的代码托管站点以获取数据。

由于国内无法访问Go官方的proxy，因此我一般会将我的工作环境下的GOPROXY设置为：

export GOPROXY=https://goproxy.cn,自己在国外主机使用athens搭建的代理,direct

3) GOSUMDB

我们知道go会在go module启用时在本地建立一个go.sum文件，用来存储依赖包特定版本的加密校验和。同时，Go维护下载的软件包的缓存，并在下载时计算并记录每个软件包的加密校验和。在正常操作中，go命令对照这些预先计算的校验和去检查某repo下的go.sum文件，而不是在每次命令调用时都重新计算它们。

在日常开发中，特定module版本的校验和永远不会改变。每次运行或构建时，go命令都会通过本地的go.sum去检查其本地缓存副本的校验和是否一致。如果校验和不匹配，则go命令将报告安全错误，并拒绝运行构建或运行。在这种情况下，重要的是找出正确的校验和，确定是go.sum错误还是下载的代码是错误的。如果go.sum中尚未包含已下载的module，并且该模块是公共module，则go命令将查询Go校验和数据库以获取正确的校验和数据存入go.sum。如果下载的代码与校验和不匹配，则go命令将报告不匹配并退出。

Go 1.13提供了GOSUMDB环境变量用于配置Go校验和数据库的服务地址（和公钥），其默认值为”sum.golang.org”，这也是Go官方提供的校验和数据库服务(大陆gopher可以使用sum.golang.google.cn)。

出于安全考虑，建议保持GOSUMDB开启。但如果因为某些因素，无法访问GOSUMDB（甚至是sum.golang.google.cn），可以通过下面命令将其关闭：

go env -w GOSUMDB=off

GOSUMDB关闭后，仅能使用本地的go.sum进行包的校验和校验了。

4）面向私有模块的GOPRIVATE

有了GOPROXY后，公共module的数据获取变得十分easy。但是如果依赖的是企业内部module或托管站点上的private库，通过GOPROXY（默认值）获取显然会得到一个失败的结果，除非你搭建了自己的公私均可的goproxy server并将其设置到GOPROXY中。

Go 1.13提供了GOPRIVATE变量，用于指示哪些仓库下的module是private，不需要通过GOPROXY下载，也不需要通过GOSUMDB去验证其校验和。不过要注意的是GONOPROXY和GONOSUMDB可以override GOPRIVATE中的设置，因此设置时要谨慎，比如下面的例子：

GOPRIVATE=pkg.tonyba.com/private
GONOPROXY=none

GONOSUMDB=none

GOPRIVATE指示pkg.tonybai.com/private下的包不经过代理下载，不经过SUMDB验证。但GONOPROXY和GONOSUMDB均为none，意味着所有module，不管是公共的还是私有的，都要经过proxy下载，经过sumdb验证。前面提到过了，GONOPROXY和GONOSUMDB会override GOPRIVATE的设置，因此在这样的配置下，所有依赖包都要经过proxy下载，也要经过sumdb验证。不过这个例子中的GOPRIVATE的值也不是一无是处，它可以给其他go tool提供私有module的指示信息。

3. Go错误处理优化迈出第一步

Go核心团队早在一年前就提出了关于go错误处理的多个proposal，其中涉及解决if err != nil 大量重复问题的，有解决错误包装(wrap)问题的，有解决error value比较问题的。在Go 1.13中，Go核心团队落实了后两个：

通过标准库增加了errors.Is和As函数来解决error value比较问题
增加errors.Unwrap来解决error unwrap问题。

并且Go通过在fmt.Errorf中新增的”%w”动词来协助Gopher快速创建一个包装错误，创建的error变量实现了下面接口：

interface { // 一个匿名接口

    Unwrap() error

}

关于Go 1.13中错误处理的改进，Go官方发表了一篇博客《Go 1.13中的错误处理》给出了十分详尽的说明，这里就不赘述了。

4. 性能

个人觉得Go 1.13中能带来性能提升的变动主要有三个：

第一个就是defer的性能提升。

defer语法让Gopher在进行资源(文件、锁)释放的过程变动优雅很多，也不易出错。但在性能敏感的应用中，defer带来的性能负担也是Gopher必须要权衡的问题。在Go 1.13中，Go核心团队对defer性能做了大幅优化，官方给出了在大多数情况下，defer性能提升30%的说法。

这里可以来验证一下：我们使用Go 1.13和Go 1.12.7两个版本运行同一个benchmark(macos 1.6G 8核 16G内存)：

// github.com/bigwhite/experiments/go1.13-examples/defer_benchmark_test.go

package defer_test

import "testing"

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        defer func() {
                sum(10)
        }()

        sum(100)
}

func BenchmarkDefer(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

go 1.13下的benchmark结果：

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       17341530            67.3 ns/op
PASS
ok      command-line-arguments    1.245s

go 1.12.7下的benchmark结果：

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       20000000            76.5 ns/op
PASS
ok      command-line-arguments    1.618s

我们看到性能的确有提升，但没有到30%这么大幅度，也许这仅仅是一个个例吧。
第二个是优化后的逃逸分析(escape analysis)让编译器在选择究竟将变量分配在stack上还是heap上的时候更加精确。在老版本里分配到heap上的变量，在Go 1.13中可能就会分配到stack上，从而减少内存分配的次数，一定程度上减轻gc的压力，达到性能提升的目的。

第三个是sync包中Mutex、RWMutex的方法的inline化带来的性能提升，官方说法是10%。我们同样来benchmark一下：

// github.com/bigwhite/experiments/go1.13-examples/mutex_benchmark_test.go

package mutex_test

import (
        "sync"
        "testing"
)

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        var mu sync.Mutex
        mu.Lock()
        sum(10)
        mu.Unlock()
}

func BenchmarkMutex(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

Go 1.13下的结果：

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       43395768            26.4 ns/op
PASS
ok      command-line-arguments    1.182s

Go 1.12.7下的结果：

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       50000000            28.4 ns/op
PASS
ok      command-line-arguments    1.457s

从结果看，提升在7%左右，约等于10%吧。

5. 其他变化

简单罗列一些我认为值得关注的小变化：

Go 1.13现在支持Android 10了；对MacOS的支持需要至少10.11版本；
godoc不再和go、gofmt放入go release版中，需要godoc的，需要单独从golang.org/x/tools/cmd/godoc中下载安装；
crypto/tls默认开启tls 1.3支持；
unicode包支持的unicode标准从10.0版本升级到Unicode 11.0版本

6. 小结

Go 1.13版本的发布标志着Go向着Go2的目标又迈出了坚实的一步，Go的演化节奏也是恰到好处：

go module已经落地成型，逐渐打磨到成熟；
错误处理：迈出阶段性的一步，后续持续改进
Go generics: 是Go2最大的”挑战”。我们看到在GopherCon 2019大会上，Ian Lance Taylor带来的有关Go generics的proposal的改进正在被越来越多Gopher所认可。