Golang Go语言中，作为使用者，你如何评价 go module？
Golang Go语言中，作为使用者，你如何评价 go module？
这个问题是在百度后台看到的问题，觉得挺有意思的。
因为好几次看到有人使用这个关键字搜索，索性，我就代他询问下大家。
我自己虽然也写了几篇介绍文章，但对 go module 真的是无感，既没那么兴奋，也没那么失望。
相比于其它语言，go 的模块化 /( 包 )版本化之路走的太艰辛了
我现在最期待的是 go module 带来的 proxy 功能，期待在这个 proxy 之上构建的中央仓库。
更多关于Golang Go语言中，作为使用者，你如何评价 go module？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
希望越来越好吧
更多关于Golang Go语言中，作为使用者，你如何评价 go module？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
我觉得比野生的包管理好点了，我把之前自己用 glide 管理的项目签到 go mod 了，居然直接支持迁移，执行 go mod init 直接获取了 glide.lock 里面的包了，很方便。
我只想说，包管理是很难么？为什么现代化的语言都用中心话管理，golang 就整天扯这些。
承认吧，golang 在依赖管理这方面就是个残废，就是想着自己内部有一个超级大的代码库，什么都可以从里面 checkout。
压根就没有考虑其他人的使用。1991 年发明的 Python 跟 Java 都有很成熟的包管理方案，大家都习惯这样的做法。golang 到今天还要整天发文说这个版本号管理，那个机制管理。简直是败笔，无病呻吟，自找麻烦，抄都不会抄！
- go module 所解决的是取消强制 gopath 的约束，以及 go get 的需要手动操作才能下载依赖的操作
2. 之前使用 vendor 管理工具的，几乎可以无缝切换到 go module ；并且不需要针对包管理选择而去做技术选型了
3. 官方与开源组织会一直提高 go module 的可用性，随着版本的更新，go module 会越来越可靠
但是他为什么不做？原因就是 Google 不需要，你们社区要不要，他不管。
Rob 不是圣人，要排资论辈 cpp，Java 哪个不是大牛设计？
错误就是错误，跟谁做的没关系。
历史就是明证，说泛型无用，check error 最好的，官方都在打脸。
不对就要喷，分散代码，靠 github 管理有什么好？
集中的一个源，我可以说有以下几个优点
1. 快速部署镜像
2. 不会因为 github 的地址变更而改变依赖关系。你们自己想想到底有没有 github repo 转让过用户，转让了是不是不用动代码，一个新的项目参与者能用什么方式同步依赖？
为什么 Rob 就一定要采取这样的方式来管理依赖，你们说这个没有受到 Google 内部的基础设施影响，你们自己信吗？
自从 Golang 发布依赖出现了多少依赖管理工具，为什么官方就不钦定一个？原因就是 Google 内部没有这个必要。bazel 加上单一的版本库，完全就可以解决版本控制，构建的问题。但是一般公司不是这样，这样才是为什么 2018 年了，golang 的版本控制还是如此让人蛋疼。
同时你们觉得时不时插入的 check error 没有影响思路的，我觉得也是可以，毕竟这个风格问题。问题也不大，正如没有泛型也可以自己写一个代码生成器生成代码，或者编辑器编写代码片段。但是你们倒是说说用 github 作为代码仓库有什么好处？
确实想不通，随便 找个 python 的 pip install pip freeze 挺好的，21 世纪的 C 语言了，随便抄 npm pip 都比 go get 拉 master 分支这种一看就巨傻逼的行为好很多很多，因为包管理人家拉的都是 release ……
“自从 Golang 发布依赖出现了多少依赖管理工具，为什么官方就不钦定一个？”
我怎么感觉你连标题里的“ go module ”是什么都不知道啊？ 1.10 引入了 go module，那 go 命令本身就是一个依赖管理工具了，你不知道吗？
你也是个知识没更新就瞎喷的货。
你说得对啊，现在都 1.11 了，也就上个版本。但是除了这个工具，官方还做了什么？语义化版本号对吧。降低 GOPATH 的影响是吧？
你说这些是重点吗？我上面说了那么多是说这个工具吗？我是喷官方长期不作为，而且没有建立一个中心化的仓库。
你倒是说说这个优势是什么，这个才是让人觉得巨难受的地方
官方不做，你可以去邮件提议，最终决策权在他们，多跟踪跟踪他们的社区讨论。
另外，中心化的仓库也不是必须的，因为互联网的根域服务器也都在变化，听说分配给北京的几台就因为某些因素撤销了。他们说是北京问题，北京觉得是他们不遵守北京意志。
去中心化没什么不好，docker 的 hub 似乎也变过多少回网址了！
我说错了，go module 是 1.11 引入的，可见你根本没有了解，根本就不是使用者。中心化或者非中心化，我认为没什么影响，不知道你这个并非 go 使用者的人，究竟出于何种原因觉得“难受”？你又不用，你难受什么？
官方不作为？你去看看 go 的 GitHub repo 下的 Issues 的回复速度？包括现在 go mod 的解决方案不也是 rsc 搞出来的吗？我觉得 Go Team 做的某些决定长期来看不一定是最好的 但是在当时的环境下看来 也是一个听了社区建议后一个不算差的选择。。包括 Go2 要出的 error handling 和 泛型。。这不算是打脸吧，因为社区是真的需要啊。。
我觉得你应该先讨论问题，不要是不是就扣一个非用户的帽子。退一万步哪怕我是一个不经常用的人，我也可以发表观点。相反你一个经常使用的人面对这样一个设计，你一句话没什么影响，大概 Rob 也是这样想的。
现在是 2018 年，error handling 跟泛型现在才说要做要改，如果你认为这是积极我也没办法，反正我对比了同期的语言，我认为这就是在这个特性上面不积极。
关键现在 golang 的 package 管理也不见得多去中心化，大部分依赖 github。但是这个方式无法让企业内部快速建立一个代码仓库镜像。
能说是因为 go get 和 github 的亲密关系才喜欢 golang 的吗？╮(￣▽￣")╭
实现功能—>需要轮子—>发现好的库—>go get—>github、开源、交流、学习—>自我提升—>实现功能
代理现在已经有了，叫 Athens： https://docs.gomods.io/ ，而且今年 GopherCon 大会上微软还宣布要为 Athens 贡献代码以及与 GopherSource 合作。
“大部分依赖”是用户行为，并不是 golang 所强制的，golang 也是允许自定义托管包或自定义模块仓库的：
go get -u golang.org/x/oauth2
go get -u gopkg.in/yaml.v2
go get -u k8s.io/api/…
import yaml "gopkg.in/yaml.v2"
so，不要因为 github 一家独大就认定是 golang 一个求稳的语言的错误！
一样的，比如下载 flask python<br>➜ my-app git:(master) ✗ ls<br><br>➜ my-app git:(master) ✗ pip download flask<br>Collecting flask<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/7f/e7/08578774ed4536d3242b14dacb4696386634607af824ea997202cd0edb4b/Flask-1.0.2-py2.py3-none-any.whl" rel="nofollow noopener">https://files.pythonhosted.org/packages/7f/e7/08578774ed4536d3242b14dacb4696386634607af824ea997202cd0edb4b/Flask-1.0.2-py2.py3-none-any.whl</a><br> Saved ./Flask-1.0.2-py2.py3-none-any.whl<br>Collecting Jinja2>=2.10 (from flask)<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl" rel="nofollow noopener">https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl</a><br> Saved ./Jinja2-2.10-py2.py3-none-any.whl<br>Collecting itsdangerous>=0.24 (from flask)<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/dc/b4/a60bcdba945c00f6d608d8975131ab3f25b22f2bcfe1dab221165194b2d4/itsdangerous-0.24.tar.gz" rel="nofollow noopener">https://files.pythonhosted.org/packages/dc/b4/a60bcdba945c00f6d608d8975131ab3f25b22f2bcfe1dab221165194b2d4/itsdangerous-0.24.tar.gz</a><br> Saved ./itsdangerous-0.24.tar.gz<br>Collecting Werkzeug>=0.14 (from flask)<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/20/c4/12e3e56473e52375aa29c4764e70d1b8f3efa6682bef8d0aae04fe335243/Werkzeug-0.14.1-py2.py3-none-any.whl" rel="nofollow noopener">https://files.pythonhosted.org/packages/20/c4/12e3e56473e52375aa29c4764e70d1b8f3efa6682bef8d0aae04fe335243/Werkzeug-0.14.1-py2.py3-none-any.whl</a><br> Saved ./Werkzeug-0.14.1-py2.py3-none-any.whl<br>Collecting click>=5.1 (from flask)<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/fa/37/45185cb5abbc30d7257104c434fe0b07e5a195a6847506c074527aa599ec/Click-7.0-py2.py3-none-any.whl" rel="nofollow noopener">https://files.pythonhosted.org/packages/fa/37/45185cb5abbc30d7257104c434fe0b07e5a195a6847506c074527aa599ec/Click-7.0-py2.py3-none-any.whl</a><br> Saved ./Click-7.0-py2.py3-none-any.whl<br>Collecting MarkupSafe>=0.23 (from Jinja2>=2.10->flask)<br> Using cached <a target="_blank" href="https://files.pythonhosted.org/packages/4d/de/32d741db316d8fdb7680822dd37001ef7a448255de9699ab4bfcbdf4172b/MarkupSafe-1.0.tar.gz" rel="nofollow noopener">https://files.pythonhosted.org/packages/4d/de/32d741db316d8fdb7680822dd37001ef7a448255de9699ab4bfcbdf4172b/MarkupSafe-1.0.tar.gz</a><br> Saved ./MarkupSafe-1.0.tar.gz<br>Successfully downloaded flask Jinja2 itsdangerous Werkzeug click MarkupSafe<br><br>➜ my-app git:(master) ✗ ls<br>Click-7.0-py2.py3-none-any.whl MarkupSafe-1.0.tar.gz<br>Flask-1.0.2-py2.py3-none-any.whl Werkzeug-0.14.1-py2.py3-none-any.whl<br>Jinja2-2.10-py2.py3-none-any.whl itsdangerous-0.24.tar.gz<br><br>➜ my-app git:(master) ✗ <br>
go.mod 中可以自己 replace 的，我是觉得很方便，以前还得自己 clone 后替换，现在直接一行代码搞定了。<br>replace (<br> <a target="_blank" href="http://golang.org/x/net" rel="nofollow noopener">golang.org/x/net</a> v0.0.0-20181220203305-927f97764cc3 => <a target="_blank" href="http://github.com/golang/net" rel="nofollow noopener">github.com/golang/net</a> v0.0.0-20181220203305-927f97764cc3<br> <a target="_blank" href="http://golang.org/x/sync" rel="nofollow noopener">golang.org/x/sync</a> v0.0.0-20181221193216-37e7f081c4d4 => <a target="_blank" href="http://github.com/golang/sync" rel="nofollow noopener">github.com/golang/sync</a> v0.0.0-20181221193216-37e7f081c4d4<br> <a target="_blank" href="http://golang.org/x/sys" rel="nofollow noopener">golang.org/x/sys</a> v0.0.0-20181228144115-9a3f9b0469bb => <a target="_blank" href="http://github.com/golang/sys" rel="nofollow noopener">github.com/golang/sys</a> v0.0.0-20181228144115-9a3f9b0469bb<br> jhy/core => ../core<br>)<br><br>
最后一个是我本地上层目录中自己写的一个包
在Golang（Go语言）中，go module作为官方的依赖管理工具，无疑为开发者带来了诸多便利和优势。以下是我对go module的评价：
首先，go module极大地简化了依赖管理。在go module出现之前，Go语言的依赖管理相对分散和复杂，需要手动管理GOPATH和vendor目录。而go module通过引入模块化的概念，使得依赖关系更加清晰和易于管理。
其次，go module支持语义化版本控制。这意味着开发者可以明确指定依赖库的版本，从而避免由于依赖库更新而带来的不兼容问题。同时，go module还提供了依赖库的版本升级建议，帮助开发者更好地管理依赖库的版本。
此外，go module的初始化、拉取和更新等操作都非常简单快捷。通过简单的命令行指令，开发者就可以轻松地完成依赖库的初始化和更新操作，大大提高了开发效率。
当然，go module也存在一些不足之处。例如，在某些情况下，go module的依赖解析可能会变得复杂和难以预测。同时，由于Go语言的社区和生态系统非常庞大，一些第三方库可能还没有完全迁移到go module，这可能会给开发者带来一些额外的麻烦。
总的来说，go module作为Go语言官方的依赖管理工具，具有诸多优点和便利之处。尽管它还存在一些不足之处，但相信随着Go语言的不断发展和完善，go module将会变得更加成熟和稳定，为开发者带来更好的使用体验。
