Russ Cox（Go 核心开发团队技术 leader，下简称"rsc"）昨日公开发布邮件，称如果没有意外情况，Go 1.18 将会支持泛型。
rsc 表示，泛型是 Go 1 发布以来 Go 语言最重要的变化，同时也是有史以来最大的单一语言特性变化。他写这封邮件主要是解释为 Go 加入泛型对 Go 开发团队以及其他开发者的意义。
rsc 认为，Go 的任何新特性——无论是库或者语法，都具有不确定性。同样的，泛型也无法避免这种不确定性。而且由于泛型是一个较大的新特性，因此它带来的不确定性也会相应地更大。虽然他们为 Go 语言带来了泛型，但他们自己并不了解使用泛型的最佳实践是什么，所以无法在文档给出关于何时使用泛型以及何时不使用的准确、明确答案。
此外，Go 团队没有任何在生产环境使用泛型的经验，因此 rsc 表示他们会在发布说明中明确指出，在生产环境中使用泛型应该适当地谨慎处理。
rsc 强调了 Go 1.18 与其他 Go 1.x 版本一样具有向后兼容的承诺：他们不会破坏使用 Go 1.18 构建的代码的兼容性，包括使用泛型的代码。最坏的情况下，如果发现 Go 1.18 语义存在致命的问题，并需要进行更改（例如在 Go 1.19 中提供更改），他们会使用 go.mod 文件的 go line 来确定该模块中的源文件符合 Go 1.18 还是 Go 1.19+ 语义（预计不需要使用这种方法）。
rsc 还提到，第三方工具可能不会在 Go 1.18 发布时就完全支持泛型。他们正在与许多工具的作者沟通，尽量确保他们尽快更新，但每项工具都有自己的时间安排表。
对于“为什么不把「泛型」作为可选项提供”的疑问，rsc 也进行了解释。他表示，在这方面，减少不确定性的唯一方法是默认提供泛型。rsc 用 vendoring 举例，他说道，当 Go 团队在 Go 1.5 将 vendoring 作为可选项提供时，发生的情况是几乎没有人真正使用它，直到 Go 1.6 默认启用。另一方面，Go 1.5 版本将 Go 生态分裂成“在标准 Go 下运行的代码”和“在启用 Vendoring 后 Go 运行的代码”。现在他们希望尽可能避免泛型也出现这种情况。
戴着JVM运行，不爽、膈应、憋屈、痛苦，还得学习JVM调优，这是人干的事吗？