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。會帶來下述問題：
- 從語言層面來看：肯定是不直觀的，培訓和交流工程運行環境，還得問問人家是跑在 GOPATH，還是 Go modules 上。
- 從設計層面來看：這不符合 Go 語言標榜的簡潔，少即是多的理念，冗余的老理念。
- 從實際經驗來看：最常見的就是新老項目的維護，你可能需要關注這個項目到底用的什么，再調整自己拉取依賴的行為(GOPATH 拉依賴需要爬梯)。
- 從麻煩的角度來看：在 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。大家不用太心急，大概率會通過其他方式軟實現這個目的。
