Go1 要不要移除 GOPATH？

本文转载自微信公众号「脑子进煎鱼了」，作者陈煎鱼。转载本文请联系脑子进煎鱼了公众号。  

大家好，我是正在学习蒸鱼的煎鱼。

前几天 Go 语言社区被 《Go1.17 快报：将移除 GOPATH》，以及最近 Go1.16 的 Go modules 变动引爆社区浪潮。

经过三天冷静期，现在整体热度基本降下来了。煎鱼打算从另外一个角度来聊下，看看移除 GOPATH 是怎么回事?

希望给大家带来新的思考。

什么是 GOPATH

GOPATH 是 Go 语言早期的一个产物，说白了就是一个环境变量，能够指定 Go 工程的工作目录。重点是 Go 代码必须跑在 GOPATH 下，不具备各种依赖版本控制的各种功能(要命)。

图来自某付费专栏

此时就有小伙伴疑惑了，Google 这么大的公司了，代码量那么庞大，居然还是这种模式?

主要原因是 Google 是大仓库的模式，有自己独特的代码治理模式，不存在业界的这类使用场景，也自然也就不存在了。

为什么推动 Go mod

官方没有提供，社区/业界又需要。自然而然的，后面社区诞生了一大堆第三方的依赖管理，杂乱丛生。

直到 Go 官方被迫出手，也吵不齐，无法统一意见。最后由 rsc 强行力排众议强行推进 Go modules。

Go modules 争议最大的时候，rsc 被社区喷了好久，现在黑转粉居多了。

为什么移除 GOPATH

在 Go 语言中存在两种可用项目管理模式：一种 GOPATH，另外一种 Go modules。会带来下述问题：

1. 从语言层面来看：肯定是不直观的，培训和交流工程运行环境，还得问问人家是跑在 GOPATH，还是 Go modules 上。
2. 从设计层面来看：这不符合 Go 语言标榜的简洁，少即是多的理念，冗余的老理念。
3. 从实际经验来看：最常见的就是新老项目的维护，你可能需要关注这个项目到底用的什么，再调整自己拉取依赖的行为(GOPATH 拉依赖需要爬梯)。
4. 从麻烦的角度来看：在 GOPATH 迁移到 Go modules 时很容易踩坑。在 IDE 的模式上切来切去也比较痛苦，Go 内部源码也得处理两套逻辑。

这么错综复杂，任何一个程序员可能都不会太想维护两套，何况是简洁为设计原则的 Go 语言团队。

社区意见征集

早在 2018 年，rsc 就针对 Go modules 和 GOPATH 表示过其观点：

从长远来看，对于 Go modules，我们预计大家会停止设置 GOPATH，那么 GOBIN 可能会更重要(或者说会增加压力，默认为 GOPATH[0]/bin)。

再结合消息的来源，也就是 Go 官方博文《New module changes in Go 1.16》：

原意更多是 “计划”，留意到最后标有 “如果存在阻止您迁移的问题，请考虑提交 issue 或 experience report。”

结合表述和经验，可以明确面向未来 “移除 GOPATH” 是技术上正确的决策。但从 Go 历史项目来看，这可能违背了 Go1 兼容性承诺。

假定你有一个 Go 历史项目在维护。你不知道 Go1.17 彻底移除了 GOPATH，直接升级了，那程序直接就崩了。又或是你的镜像默认拉取的就是 lastest，那就刺激了。

总结

Go 官方这篇《New module changes in Go 1.16》在宣传的同时，也包含着 Go 官方向社区征集意见的作用。

目前从国内的评论区来看，绝大部分都是支持移除的。但其实有难处的小伙伴，早已经在 issues 反馈了：

回到起步那个问题，这个问题放大来看是 “Go1 要不要移除 GOPATH”。而 Go1.17 能否彻底移除 GOPATH，还是个待讨论的事项：

目前来看，Go 官方仍在摸索 GOPATH 的未来，也不一定是完全移除 GOPATH。大家不用太心急，大概率会通过其他方式软实现这个目的。