来源：脑子进煎鱼了

大家好，我是煎鱼。

最近 Go 核心团队负责人 @Russ Cox（下称：rsc）发起了一项 “讨论”。希望正式开启 Go 标准库的 v2 版本，相当于老树发新芽了。

Go 标准库升级 v2 原因

这次会发起这个提案的最直接原因是：我们（指的 Go 团队）要清理 math/rand 标准库的脏乱差，修复许多挥之不去的问题，特别是使用过时的生成器、缓慢的算法（性能），以及与 crypto/rand.Read 的不幸冲突。

间接且重要的原因是：

• 为标准库中的其他 v2 包树立一个榜样。创建 math/rand/v2 可以让我们在一个相对较少使用的包中解决工具问题（gopls、goimports 等工具对 v2 包的支持）。
• 后续要对更常用、风险更高的包（如：sync/v2 或 encoding/json/v2）进行新版本迭代，先以 math/rand/v2 来升级，风险低很多。

总结一下，三点：

1. 标准库里的 math/rand 和其他包的老毛病和待提高的地方太多了。
2. Go1 要求兼容性保障，没法直接改。
3. 我们要推动标准库的 v2 版本升级。

math/rand 问题清单

那针对 math/rand 本身有哪些问题呢，rsc 也拉了一份清单，证明本次升级 v2 版本的原因和计划改造的地方。

对于完整实现感兴趣的同学可以查看 502506: math/rand/v2: delete Mitchell/Reeds source^[1]：

以下是快速概览：

• 删除 Rand.Read 和顶层的 Read。
• 移除 Source.Seed、Rand.Seed 和顶层 Seed。（意味着像 Int 这样的顶层函数将总是随机播种）
• 移除 Source64，现在 Source 提供了 Uint64 方法，原有的方法没有必要存在了。
• 在 Float32 和 Float64 中使用更直接的实现。以 Float64 为例，它最初使用 float64(r.Int63()) / (1<<63)。但这有一个问题，就是偶尔会四舍五入到 1.0，而 Float64 一定不会。我们期望改成 float64(r.Int63n(1<<53)) / (1<<53)，这就避免了四舍五入的问题。
• 用 Rand.Shuffle 的方式实现 Rand.Perm。Shuffle 的效率更高一些，这样可以确保只有一个实现。
• 将 Int31、Int31n、Int63、Int64n 更名为 Int32、Int32n、Int64、Int64n。这些名字是不必要的迂腐和混乱。
• 添加 Uint32, Uint32n, Uint64, Uint64n, Uint, Uintn，将会是 Rand 上的顶级函数和方法。
• 在 Intn, Uintn, Int32n, Uint32n, Int64n, Uint64n 中使用 Lemire 的算法。性能会有新的突破。
• 添加一个新的 Source 实现，PCG-DXSM，包含以下 API：

func NewPCG(seed1, seed2 uint64) *PCG
type PCG struct { ... }
func (p *PCG) Uint64() uint64
func (p *PCG) Seed(seed1, seed2 uint64)

• 删除 Mitchell & Reeds LFSR 生成器和 NewSource。

总结

Go 近年在推动了 Go1 向前向后兼容性保障和策略后，似乎正期望在对既有的组件们进行大修整。

这次 math/rand 将会打响的 Go 标准库 v2 升级的前哨战。后续 sync/v2 和 encoding/json/v2 也陆续有来。值得期待！

但是最近我关注到，现在 Go 较大的东西基本都是 rsc 在推动和改造。不知道 Go 核心团队是否也出现了一些青黄不接？这是一个值得担忧的点。

参考资料