映客解析php技巧_解读Go措辞的2020变革前夜

文章目录 [+]

在作者去年年底撰写《解读Go措辞的2019》的时候，绝没有想到 2020 年将会如此的不平凡。
环球范围内的疫情在大大地限定了人们和企业的对外活动之余，还带来了一个副浸染，即：线下活动向线上的迅速迁移。

实际上，对付这种迁移，我们海内的民营企业和奇迹单位早就在做了，只不过在 2020 年之前还没有这么急迫。
不知道你创造了没有，在 2020 这一年，那些已经存在的远程办公、视频会议、在线医疗、在线教诲等方面的根本举动步伐和运用程序给予了我们莫大的支撑。
即便说它们赞助保障了社会的正常运转，也不为过。

映客解析php技巧_解读Go措辞的2020变革前夜

目前来看，环球的疫情还会存在一段韶光。
虽然这个事宜本身绝对不值得高兴，但是反过来想，这会倒逼海内数字经济的大踏步提高，乃至飞跃。

（图片来自网络侵删）

从根本层面讲，数字经济的发展必须要有半导体等高精尖领域的强力支持。
而从运用层面说，数字经济将会依托于云打算、大数据和人工智能。
更详细地说，云打算是高等的根本举动步伐，大数据和人工智能是建立在云打算之上的高等运用。
Go 措辞，早已霸占了云打算的大半个江山，今后它也将在大数据和人工智能方面发挥主要浸染。

趋势纵览

下面，我们依旧先从整体趋势上看看 Go 措辞在今年的发展。

在环球范围内，从 2010 年的集体追新，到之后几年内的理性对待，再到 2016 年、2017 年的“第二春”，直至 2018 年的升降大反差和 2020 年的新反弹。
Go 措辞可谓是经历了诸多风风雨雨，持续地在各种好评和诟病之间雕琢前行，既得意过也失落意过。

下图展现了 TIOBE Index（著名编程措辞排行榜）对 Go 措辞利用情形的最新统计。

图 1 - TIOBE Index 之 Go 措辞（2020 年 12 月）

图 2 - TIOBE Index（2020 年 12 月）

我们从上面这两幅图中可以看出， Go 措辞在今年的排名又有了大幅的提升。
作者个人认为，这与 go mod 工具的转正和推广，以及“泛型”实现的排期确定是分不开的。

同时，据 StackOverflow（环球最大的编程社区和问答网站）在前不久发布的一份开拓者生存报告显示，Go 措辞在 2020 年是继 Python、Java、C++和 C 之后、排名第五的通用型、全平台编程措辞。
如果把脚本措辞和标记措辞都算在内的话，它的总排名是第 12 名。

图 3 - Stack Overflow Servey 2020 - The Most Popular Languages

不但如此，Go 措辞在“最喜好”和“最须要”的编程措辞排行中也名列前茅。

图 4 - Stack Overflow Servey 2020 - The Most Loved Languages

图 5 - Stack Overflow Servey 2020 - The Most Wanted Languages

我们可以看到，Go 措辞不但是开拓者们非常喜好的编程措辞之一（“最喜好”排行榜第五名），而且从实际运用的角度看，大家也是非常须要它的（“最须要”排行榜第三名）。
作者认为，正由于 Go 措辞有着崇尚简约和实用主义的编程哲学，广大软件工程师才会如此地爱用它。

更主要的是，Go 软件工程师的薪资报酬也是相称不错的。

图 6 - Stack Overflow Servey 2020 - The Highest Salaries

你可能会奇怪，为什么 Perl 程序员的薪资排在了第一位？这可能是由于物以稀为贵，Perl 程序员在当代已经非常少见了。
而在当今很热门的通用型编程措辞中，从薪资角度来看，Scala 措辞、Go 措辞和 Rust 措辞都有着相称大的上风。

当然了，这是在环球范围内的情形，并且参与这份调查的中国开拓者并不多。
很可惜，作者没能找出一份公认且威信的海内开拓者调查报告。

不过，从作者的亲自经历来看，Go 措辞在海内恐怕并不亚于国际上的热度，乃至还要更火热一些。

作者这两年一贯在断断续续地帮助一些互联网企业招聘 Go 软件工程师。
除了作为老一代霸主的 BAT（百度、阿里巴巴、腾讯）以及作为新一代俊彦的 TMD（今日头条、美团、滴滴）之外，还有很多有名的互联网公司都在招聘节制 Go 措辞的开拓工程师和系统运维职员。
像 PingCAP、七牛、哔哩哔哩、探探、Grab 这些公司，在很早以前就混迹于 Go 措辞圈子了。
而在最近几年才进入 Go 措辞圈子的有名公司还有华为、小米、映客、云智联、轻松筹、贝壳网、美菜网、游族网络等等。
就连刚开始大红大紫的工业互联网领域，也有不少公司选择 Go 措辞作为其主力开拓措辞之一。
比如，积梦智能、必可测等。

这么多的精良企业，以及生动在技能社区中的大佬和新秀共同营造出了 Go 措辞工程师的供需网络。
作者认为，在海内的做事端编程市场，除了 Java 和 PHP，就当属 Go 措辞了。

2020 年回顾

在理解了 Go 措辞的发展趋势之后，我们再一起来看看它在 2020 年都有哪些主要的更新。

模块：终于稳定

自 2020 年 2 月份发布的 1.14 版本起，Go 措辞官方就开始正式地推广 go modules 了。
这解释它已经完备可以在天生环境中利用了。

如果你是老牌的 Go 工程师的话，那么肯定利用过像 glide、dep、govendor 这类第三方的依赖管理工具。
这些工具都非常的精良，并且在很大程度上办理了我们在项目开拓过程中碰着的痛点。

不过，现在是时候迁移到 go modules 了。
Go modules 综合了这些第三方工具的优点，并经历了数年的设计和磨合，终极成为了 Go 程序依赖管理的官方工具。

纵然现存的项目已经利用了前面提及的某一个依赖管理工具，那么也无需担心。
我们只须要在 Go 项目的根目录中运行命令“go mod init <项目主模块的导入路径>”就可以实现自动地迁移。
go mod 命令会读取那些已经存在的依赖配置文件，然后在其创建的 go.mod 文件中添加相应的内容。
不过在这之后，我们最好再次利用 go build 命令构建一下项目并运行相应的单元测试，以确保统统正常。

还记得系统环境变量 GOPATH 吗？现在的 go 命令会自动地把项目所需的依赖包下载到它指向的第一个事情区目录中的 pkg/mod 子目录里。
这里有一点须要把稳，如果我们的项目中存在处于顶层的 vendor 目录，那么 go 命令将会优先在该目录中查找对应的依赖包。

如果我们利用的是 Go 措辞的 1.15 版本，那么也可以通过设置系统环境变量 GOMODCACHE 来自定义上述存储依赖包的目录。
这实际上是为往后彻底废弃 GOPATH 埋下的一个伏笔。

其余，实行一下 go mod tidy 命令也是一个很好的主张。
这个命令会对 go modules 的依赖配置文件进行整理，添加那些实际在用的依赖项，并去除那些未用的依赖项。
换句话说，它会确保项目的依赖配置文件与项目源码的实际依赖相对应。

Go 措辞的大多数标准命令都得到了不同程度的改进以更加适配 go modules，包括一些标记（flag）的调度和一些行为上的优化。
比如，go get 命令在默认情形下不再见去更新非兼容版本的依赖库。
不兼容的依赖库更新常常会让我们很恼火，但现在不会再涌现这种情形了。

环境变量：跟进的调度

Go 措辞可识别的系统环境变量 GO111MODULE 在 1.14 和 1.15 版本中的默认值都是 auto。
这意味着，go 命令仅在当前目录或上层目录中存在 go.mod 文件的情形下才会以 go modules 的办法运行，否则它就会退回到之前以 GOPATH 为中央的运行办法。
不过，估量在明年发布的 1.16 版本中，Go 措辞将会把这个环境变量的默认值设置为 on。
也便是说，到了那时，GOPATH 这一古老但能勾起我们满满回顾的东西终于要默默地退出了。

其余，我们现在可以在系统环境变量 GOPROXY 的值中利用管道符“｜”了。
在这之前，GOPROXY 的值中只能涌现分隔符“，”。
如果一个代理 URL 跟在了分隔符后面，那么只有在前一个代理 URL 指向的做事器返回 404 或 401 缺点时，go 命令才会考试测验利用当前的代理 URL。
现在，如果一个代理 URL 跟在了管道符后面，那么只要在访问前一个做事器时发生了（任何的）缺点，go 命令就会立时利用当前的代理 URL。
换句话说，新的管道符让我们多了一种容错的选择，即范围更广的容错。
合理利用它，可以让我们更快地从可用的代理那里下载到所需的代码包。

顺便说一下，我们现在有了一个新的系统环境变量 GOINSECURE。
这个环境变量的存在纯挚是为了让我们能够从非 HTTPS 的代码经办事器高下载依赖包（或者模块）。

有关环境变量的更多细节，我就不在这里说了。
大家如果想理解的话，可以去参看 Go 措辞的干系文档。

措辞语法：可重叠的接口方法

我们都知道，Go 措辞这些年在语法方面一向很稳定，少有改动，更没有不兼容的变革涌现。
在 2020 年，Go 措辞只做了一项语法改进。
这是关于接口声明的，并且完备担保了向后兼容性。
我们下面来看一组代码示例。
假设，我们有如下两个接口声明：

// MyReader 代表可读的自定义接口。 type MyReader interface { io.ReadCloser}// MyWriter 代表可写的自定义接口。 type MyWriter interface { io.WriteCloser}

在 Go 1.14 之前，这两个接口是无法内嵌到同一个接口声明中去的。
就像这样：

// MyIO 代表可输入输出的自定义接口。 type MyIO interface { MyReader MyWriter io.Closer}

这会让 Go 措辞的编译器报错。
报错的缘故原由是：在同一个接口声明中创造了重复的方法声明。
更详细地说，Go 措辞标准库中的 io.ReadCloser 接口和 io.WriteCloser 接口都包含了一个名为 Close 的方法，而分别内嵌了这两个接口的 MyReader 和 MyWriter 又已经嵌入到了接口 MyIO 之中。
这导致 MyIO 接口里现在存在两个 Close 方法的声明。
以是，MyIO 的声明是无效的，并且无法通过编译。

这看上去是合规的，但却不一定合理。
由于在很多情形下，我们想做的只是把多个接口合并在一起，而不在乎方法声明是否有重叠。
我们一样平常认为，如果有重叠的方法，那么就当作一个就好了。
很可惜，之前的 Go 措辞并不这么认为。
更主要的是，对付像上面那样深层次的接口内嵌问题，我们排查和解决起来都会很麻烦。
有时候，这还会涉及到第三方库。

值得光彩的是，自 Go 1.14 开始，我们的这个合理诉求终于得到了知足。
Go 措辞的语法已经认可了上述情形。
这将给我们的接口整合事情带来极大的便利。

不过请把稳，Go 措辞只接管在同一个接口声明中完备重叠的多个方法声明。
换句话说，只有这些方法声明在名称和署名上完备同等，它们才能够合而为一。
别忘了，接口中方法的署名包括了参数列表和结果列表。
如果仅名称相同但署名不同，那么 Go 措辞编译器还是会报错。
例如：

// MyIO 代表可输入输出的自定义接口。 type MyIO interface { MyReader MyWriter Close()}

由于这里末了面的方法声明 Close() 与接口 io.ReadCloser 和 io.WriteCloser 中的方法声明 Close() error 不完备同等（请把稳结果声明上的差异），以是 Go 措辞仍旧会报出错误“duplicate method Close”，并使得程序编译不通过。

运行时内部：性能提升

Go 措辞每次的版本更新都会包含针对其运行时系统的性能提升。
在 2020 年的优化中，有几点值得我们把稳：

1. goroutine 真正实现了异步的抢占。
也便是说，现在纵然是不包含任何函数调用的 for 循环也绝不会引动身序的去世锁和垃圾回收的耽误了。

2. defer 语句的实行效率又得到了进一步的提升，额外的开销已险些为零。
以是，我们已经完备可以将 defer 语句用在对性能有严苛哀求的运用处景中了。

3. 运行时系统内部的内存分配器得到了改进。
这使得在系统环境变量 GOMAXPROCS 有较高数值的情形下，内存的申请效率会得到大幅的提升。
这间接地让运行时系统的整体性能明显提高。

除了以上这些，Go 措辞运行时系统还有一些比较小的改进，比如：panic 函数已经可以精确地打印出我们传入的参数值当中的各种数值了、在将较小的整数值转换为接口值的过程中不再见引起内存分配、针对通道的非壅塞吸收操作得到了进一步的优化，等等。

并发编程：一些微调

我们都知道，runtime.Goexit 函数在被调用之后会中止当前的 goroutine 的运行。
然而，在嵌套的 panic/recover 处理流程中，程序对它的调用会被忽略掉。
虽然这种运用处景非常少见，但终归是一个问题。
幸好自 Go 1.14 开始，这个问题被彻底地办理了。

还要把稳，如果 runtime.Goexit 函数被主 goroutine 中的代码调用了，那么它并不会终止全体 Go 程序的运行，而只会中止主 goroutine 而已。
在这种情形下，其他的 goroutine 会连续运行。
如果，在这之后，这些其他的 goroutine 都运行完毕了，那么程序就会崩溃。
以是说，我们千万不要在主 goroutine 中调用 runtime.Goexit 函数。

在同步工具方面，现在的 Go 运行时系统会更加关注那些竞争非常激烈的互斥锁。
一旦这样的锁被解锁，系统会立即安排 CPU 去运行正在等待该锁的下一个 goroutine（也便是说，它会跳过调度的过程）。
这显然可以大大提高此类场景下的互斥锁性能。

并发安全字典 sync.Map 有了一个新方法 LoadAndDelete。
从方法名上我们也可以看得出来，这个方法能够在获取某个元素值的同时把它从字典中删除掉。
更主要的是，Go 措辞会担保这个“获取+删除”的操作的原子性。
其余，该方法返回的第二个结果值会奉告我们，字典先前是否包含与我们传入的健值（key）对应的元素值（element）。
如果不包含，那么它返回的第一个结果值就会是 nil。

再来说 context.Context。
虽然它并不在 sync 代码包中，但是我们常常用它来做高下文的同步。
因此，它也算是一个很主要的同步工具。
关于它的调度很大略也很明确，那便是：不再许可利用 nil 作为父级的高下文来创建衍生的 Context 实例了。
这一哀求显然是合理的，由于所谓的衍生 Context 就该当有实实在在的父级。
然而，在 Go 1.15 之前，并没有专门的防卫语句来对此进行前置检讨。
此项改进涉及到了 context 包中的几个主要函数，如 WithCancel、WithDeadline、WithTimeout 和 WithValue。
现在，如果我们传给这些方法的第一个参数值是 nil，那么它们都将会立即抛出包含了对应缺点信息的 panic。

标准库：新的散列算法包

标准库中多了一个新的代码包：hash/maphash。
这是一个通用的散列算法包，可以将任意的字节序列或者字符串散列成 64 位的整数。
从名字上我们也可以看出，它能够帮助我们实现那些基于散列表的数据构造。
该包中的 Hash 类型的基本行为如下：

1. 此 Hash 类型是开箱即用的。
也便是说，我们在实例化它的时候无需额外的初始化事情，仅创建一个它的零值即可利用。

2. 不同的 Hash 实例在默认的情形下会有不同的默认种子。
因此，这些默认实例为同一个工具打算出的散列值将会不同。

3. Hash 实例许可手动设置种子（必须由 MakeSeed 函数产生）。
在单一进程中，只要种子相同，Hash 实例为同一个工具打算出的散列值就会相同。
不论进行打算的 Hash 实例是一个还是多个，都会如此。

4. 被打算的工具的表现形式可以是字节序列，也可以是字符串。
只要内容同等，不论它们因此若何的办法写入 Hash 实例的，打算出的散列值都会相同（大条件是进程和种子都相同）。

5. Hash 实例可以被重置。
此操作会清空已写入当前 Hash 实例的内容，但并不会改变当前的种子。

总之，hash/maphash.Hash 类型代表着一种基于种子的、可重用、可重置、稳定、通用的散列算法。
这种算法的上风是可以有效地避免散列冲突，但它并不是加密安全的。
如果你的关注点是加密安全，那么可以考虑利用标准库 crypto 包中的算法包，如 md5、sha256、sha512 等。

单元测试：资源清理

今年，Go 措辞还在单元测试方面做了一些改进。

作者认为最实用的一项改进当属 Cleanup 方法的增加。
更详细地说，现在 testing.T 类型和 testing.B 类型都有了这个方法。
该方法接管一个函数作为其参数值。
我们的测试代码可以多次调用 Cleanup 方法，以传入多个函数。
这些函数都会被记录在测试程序的内部。
当测试即将结束的时候，这些函数就会被逐一调用，且越晚传入的函数会越先被调用。

虽然 Cleanup 方法的文档中并没有规定这些被传入的函数该当做什么。
但正如其名，它们最该当做的是清理在测试运行的过程中用到的各种资源。

其余，testing.T 类型和 testing.B 类型还各自多了一个名为 TempDir 的方法。
这个方法会返回一个临时目录的路径。
这样的临时目录是专门为当前的测试实例创建的。
并且，这些目录会在测试即将结束的时候被自动地删除掉。
因此，我们可以在测试的过程中根据实际须要在这样的目录下创建一些临时的文件，以帮助测试更好的进行。

时区信息：独立性增强

Go 1.15 包含了一个新的代码包 time/tzdata。
该包许可将时区数据库嵌入到 Go 程序当中。
当我们在程序中添加导入语句（即 import _ "time/tzdata"）之后，纵然本地系统里不存在时区数据库，当出路序也完备可以精确地查询到时区信息。
其余，我们还可以通过在构建程序时追加 -tags timetzdata 来嵌入时区数据库。
当然了，天下没有免费的午餐。
这两种方法都会使 Go 程序的大小增加大约 800 KB（估量在 Go 1.16 中会降落到 350 KB）。

明年的展望

目前，可以明确的是，Go 措辞明年肯定不会有泛型和新的缺点处理机制。
如果不出意外的话，范型该当会在 2022 年发布的 1.18 版本中涌现。
而有些可惜的是，缺点处理方面的变革可能要等到 Go 2 发布的时候才能够真正的实现。

关于 Go 措辞的泛型，大家可以参看 Ian Lance Taylor 和 Robert Griesemer 在 2020 年 11 月 25 日发布的最新设计草案。
而对付新的缺点处理机制，大家可以去看Go 2设计草案中“Error handling”部分。
作者就不在这里多说了。

我们下面来看看，将要在 2021 年 2 月发布的 Go 1.16 估量会包括哪些主要的更新。
由于 1.16 版本目前还在开拓当中，因此以下所讲的内容不一定便是终极的实现。

端口：支持新的组合

大家都知道，苹果公司已经发布了他们自己研发的 CPU，并且已经运用在了自家的入门级电脑当中。
然而，很多在 macOS 操作系统上运行的软件却还没有准备好。
Go 措辞也在其列。

不过，Go 措辞打算从 1.16 版本开始支持这种新的“打算架构+操作系统”组合，代号为“darwin/arm64”。
请把稳，在当下的 Go 措辞之中实在已经存在了“darwin/arm64”，只不过现在这个代号实际上对应的是“ARM 处理器+iOS 操作系统”。
为了避免稠浊，之前的“darwin/arm64”将更名为“ios/arm64”，而 “darwin/arm64”之后将对应于“ARM 处理器+macOS 操作系统”。

模块与工具：GOPATH 即将下岗

我们在前文说过，Go 措辞估量在 1.16 版本将系统环境变量 GO111MODULE 的默认值改为 on。
这就意味着，GOPATH 以及以它为中央的程序存储和构建办法终于要向我们挥手告别了。
不过，若我们还想让 go 命令以之前的办法运行，那么还可以把该环境变量的值改成 auto。
按照老例，本文作者估计这个环境变量还会再在 Go 措辞中留存 1 或 2 个版本。

与之相应的，Go 措辞自带的各种标准工具会彻底地站在 go modules 一方。

命令 go install 将会支持安装指定版本号的代码包。
更详细地说，我们在输入命令的时候可以这样：“go install golibhub.com/mylib@v1.2.1 ”。
在这种情形下，go 命令将会忽略掉干系 go.mod 文件中的 mylib 包条款，纵然那里配置的版本号与命令参数中的不同也会如此。
顺便说一下，Go 措辞官方将会在之后的某个版本中改变 go get 命令的行为，使它只卖力下载代码包，而不再自动地进行代码包的构建和安装。
也便是说，这个“构建+安装”的动作将只由 go install 命令卖力。

其余，go build 命令和 go test 命令将不会再对 go.mod 文件进行任何的修正。
对它们来说，go.mod 文件将会是只读的。
一个相应的行为是，如果这两个命令在实行的过程中创造须要对依赖配置文件进行修正（或者说有必要调度依赖包的配置信息），那么它们将会立即报错。
这与之前在输入命令时追加标记 -mod=readonly 的行为是同等的。
这时，我们可以利用命令 go mod tidy 或 go get 来做相应的调度。

运行时 API：监测的增强

在 Go 1.16 中，将会涌现一个新的用于运行时度量的代码包 runtime/metrics。
该代码包旨在引入一种稳定的度量接口，用于从 Go 运行时系统中读取相应的指标数据。
它在功能上会取代现有的诸如 runtime.ReadMemStats、debug.GCStats 等 API，并且会更加的通用和高效。

其余，系统环境变量 GODEBUG 将可以接管一个新的选项“inittrace”。
当该环境变量的值中包含“inittrace=1”的时候，Go 运行时系统会输出有关于 init 函数的监测信息。
个中会包含对应函数的实行韶光和内存分配情形。
这将非常有利于我们不雅观察各个代码包在初始化方面的性能。

标准库：新的嵌入包

Go 1.16 的标准库中将会涌现一个新的代码包 embed。
这个包的紧张浸染是让 go 命令在编译程序的时候向其嵌入指定的外部文件。
至于嵌入什么文件，须要我们通过注释指令 //go:embed 来指定，如：//go:embed hello.txt 。
请把稳，在包含了这个注释指令的源码文件中必须要有针对 embed 包的导入语句，如：import "embed" 。

同时，这样的注释指令必须紧挨在单一变量声明语句的上方，且该变量的类型必须是 string、[]byte 或 embed.FS。
这样的话，Go 措辞就会自动地把我们指定的文件的内容转化为相应的值，并赋给这个变量。

在 //go:embed 的右边，我们可以用空格来分割多个文件路径，或者通过添加多个这样的注释指令来分别指定多个文件。
文件的路径可以是相对的，也可以是绝对的

其余，这里的文件路径还可以包含通配符，如：//go:embed image/ template/ 。
详细有哪些通配符可用，大家可以去参看 path.Match 函数的文档。

一定要把稳，如果须要嵌入多个文件，那么我们就必须把变量的类型声明为 embed.FS。
这紧张是由于，只有这个类型才能把多个嵌入文件的内容区分开来。
通过该类型的方法（Open、ReadDir 和 ReadFile），我们还可以分别拿到代表了某个文件或目录的实体，或者读取个中任何文件的内容。

究其缘故原由，构造体类型 embed.FS 的实例可以代表一个树形的文件系统。
也便是说，它可以用来表示一个拥有多个层级的文件目录。
其余，embed.FS 类型是 io/fs.FS 接口的一个实现，因此它的实例可以被运用在很多理解统一文件系统的 API 之上。
这些 API 散落在 net/http、text/template、html/template 等代码包之中。

请想象一下，如果我们在开拓一个带有 Web 页面和静态资源的软件系统，那么这将会给我们带来多么大的便利。
让单个的可实行文件包含所有的程序和资源将变为可能。

标准库：新的文件系统包

代码包 io/fs 代表了一种全新的文件系统模型。
它可以对应于任意（已支持的）操作系统中的文件系统，但并不局限于此。
该包中的核心便是我们已经在前面提及的 FS 接口，以及还未讲到的 File 接口。

大略来说，FS 接口代表了一个文件系统抽象的最小实现哀求。
个中只有一个方法声明：Open(name string) (File, error) 。
而 File 接口则代表了可以在单个文件上进行的一系列操作。
请看下面这幅图。

图 7 - io/fs 包中的接口

到目前为止，这个代码包中的接口共有 10 个。
其他的大部分接口都会内嵌 FS 接口或 File 接口。
也便是说，它们都属于核心接口的扩展。
虽然从声明上看 DirEntry 接口和 FileInfo 接口是独立的，但它们都被多个其他的接口所引用。

在仔细阅读上图或者该包的源码之后，你一定会创造，这个模型所代表的文件系统是只读的。
也便是说，个中并没有表示“写操作”的方法。

正由于这个模型可以用来表示任何树形构造的资源系统，以是作为统一的模型，它只供应了最根本的抽象。
要知道，有的资源系统便是只能读、不能写的。
比如，我们前面说过的嵌入 Go 程序的外部文件和目录就必须是只读的。
也便是说，它们在嵌入程序之后就不应该再被改变了。

为了适配这个模型，Go 措辞标准库中的不少代码包都做了相应的调度，比如：os 包、net/http 包、archive/zip 包，以及 html/template 包和 text/template 包。

这里有一些更详细的例子：

embed.FS类型用于表示嵌入的文件或目录。
它实现了io/fs包中的FS接口、ReadDirFS接口和ReadFileFS接口；新的os.DirFS函数可以供应由当前的操作系统支持的io/fs.FS接口实现；新的http.FS函数和http.FileServer函数可以把io/fs.FS接口的实例包装成http.Handler；新的testing/fstest包专门用于测试相应的文件系统模型，个中还包含了一个基于内存的文件系统抽象MapFS。

总之，代码包 io/fs 代表了一个全新的、统一的文件系统（或者说资源系统）的模型。
这个模型将会作为很多详细运用的底层框架。
其余，io/fs 包在往后可能会得到进一步的拓展，说不定还会发展出一些描述“写操作”的扩展接口。
作者也希望如此。

总结

好了，我们现在来轻微总结一下。
在 2020 年，Go 措辞同样做出了很多改变。
这包括已经完备稳定的 go modules、环境变量和标准工具的跟进和增强、语法上的一项主要调度——可重叠的接口方法、运行时系统的性能提升、异步编程和同步工具方面的进一步优化，以及新的散列算法包、新的单元测试赞助方法和独立的时区代码包。
这些更新表面上看起来可能并不算大，但 Go 措辞内部实在已经做了很多的改变。
有的改变是完备的，而有的改变是在为往后的目标做铺垫。

我们对 Go 措辞有着很多的期望。
但是，大饼还是要一口一口的吃。
在 2021 年，Go 措辞中的 GOPATH 将会正式宣告下岗。
同时，Go 措辞也会把一些主要的东西统一起来，比如用于运行时度量的代码包 runtime/metrics，以及代表了新的文件系统模型的代码包 io/fs。
随着 io/fs 包而来的，还有便于我们将程序和资源整合成一个单独文件的代码包 embed 和注释指令 //go:embed 。
其余，作者也非常期待 Go 措辞对“ARM+macOS”组合的支持。

目前可以估量，Go 措辞的泛型支持将会比新的缺点处理机制更早到来。
不过，Go 措辞官方在担保向后兼容性的情形下已经对现有的缺点处理 API 进行了尽可能的改进。
更何况，我们还有几个不错的缺点处理包可用，如官方的扩展包 golang.org/x/xerrors，以及已经由韶光验证的第三方包 github.com/pkg/errors 和 gopkg.in/errgo.v2。
以是当前看来，这个问题早已不那么尖锐了。

作者对 Go 措辞的发展仍旧是非常乐不雅观的，尤其是在“云原生”大行其道确当下。
在数据科学方面，七牛云的 CEO 许式伟正在带头创造对标“Python 措辞+Numpy+Pandas”和（MIT 出品的）Julia 措辞的新玩意儿——基于 Go 措辞的编程措辞Go+。
作者对此还是很看好的。
不过，听说（Apple 出品的）Swift 措辞也将在这一领域连续发力，可能会涌现“Swift Number”之类的东西，同样对标基于 Python 措辞的数据科学包。
作者相信，到了 2021 年下半年或者 2022 年，这里很可能会涌现四足鼎立的态势。
总之，有竞争才会有打破，基于 Go 措辞的生态环境依然不可限量。

示例代码

github.com/hyper0x/go2020