I like Go but Go has made some serious misteps (IMHO), which the author touches on. Dependency management in Go is so incredibly bad it's hard to fathom. Did no one on the early design team ever deal with depenencies? Java is so much better here and came years earlier. Go would've been so much better had they just copied any of the Java options from Day One.
So this versioning thing is just weird and I agree with the author. It's a strange thing to have opinions on and an even stranger opinion to have on that thing.
But the thing that gets me is the whole putting "github.com/username/module" into code is just awful.
I disagree with all of this. Go's package management system is a breath of fresh air compared to all other languages. Nobody ever has any problem grabbing dependencies. There is only one way to do it and it's built into the language runtime; if you have Go installed you can install the modules. Other applications on your system can, with no effort (virtualenv, etc.) use different versions of those modules. Dependency installation can't print messages to my terminal.
It's a joy.
Importing modules from a particular URL is a great way to handle them. No central server required! Everyone can name their module "utility utils" or whatever. And, nobody is forcing you to use Github to host your modules, you can put them on any web server you control and import them as example.com/your-thing. Decentralized. Easy to use.
If I had two complaints, they would be:
1) Library authors that think "replace" directives propagate up to consumers. They do not. They are ignored when you depend on the module. If you depend on one of these libraries and want the workaround that the author has smoothed over with a "replace" directive, you have to copy that directive to your own go.mod.
2) Library authors that distribute one go module for their super-complicated server and their super-simple client. This results in unnecessary dependency explosion. (Loki 1.x was an example of this pattern. Their server depends on things like Kubernetes, where their client only depends on net/http. But if you naively import their client, suddenly your project depends on Kubernetes.)
(2a would be no concept of test-only modules. Some modules are only needed for the tests; it would be nice to not propagate these up to consumers. It isn't an actual problem, though, just a "would be kind of nice" or "I could see why they did that" if it existed.)
Neither of these are Go issues, just maintainer issues that can happen with any language.
Everything on the Internet is vulnerable to this. NPM has gone down. You can send NPM a legal request to delete a module. Your domain registrar can take your domain name. Your local IP address registry can take away your IP address. At the end of the day, you can vendor all your modules and keep them with your source code if this worries you. It's not really in scope for a programming language to make a completely immutable and takedown-proof Internet just to let Internet users share some code with each other. But, they've done a pretty good job here.
Every non-tiny place I have worked finds it necessary to copy known working versions of code they rely on, to an internal server and build from there. You don't have reproducible builds, for example, from a remote sever (maybe there are hashes?). But even then you don't have reliable access to external servers (they may crash, be bought, be hacked, change business models). So people self-host what they use.
Can you do this in Go, without changing source code?
Not related to above, your 2) reminds me of my pet peeve: doc dependencies included in module dependencies. Oh, you use Sphinx, we'll install that. Oh, Sphinx needs Python, we'll install that. Try to use a simple, non-Python, library, get Python and all it's dependencies.
Maven naming convention is absolutely atrocious. And don't tell me that naming convention is optional. To be part of Java ecosystem Maven naming convention is a requirement.
> Dependency management in Go is so incredibly bad it's hard to fathom.
It used to be pretty terrible. Today it's at least as good as npm.
> Did no one on the early design team ever deal with depenencies?
It was developed at Google and they have a giant monorepo, associated infrastructure, as well as company policies against multiple versions of dependencies. They also vendor external deps into this repo. So no, Google deals with dependencies a lot, but they do things very, very differently from almost everyone else.
What if I publish gitlab.com/username/module and i dont know anything about your github project? This seems like a pretty obvious disadvantage, so its surprising you failed to see it. What are the advantages?
I would take this further, simply `import "module"` would be nicer. (I don't care about anyone's github username, and I often need to fork projects and today that means mindless search and replace)
Conflict resolution within the same module could be handled in the go.mod file:
So this versioning thing is just weird and I agree with the author. It's a strange thing to have opinions on and an even stranger opinion to have on that thing.
But the thing that gets me is the whole putting "github.com/username/module" into code is just awful.