There is versioning through Git tags, which I don’t consider true versioning because you can always edit those tags to point somewhere else or remove them entir

There is versioning through Git tags, which I don’t consider true versioning because you can always edit those tags to point somewhere else or remove them entirely. This is breaking. I suppose there is not an assumption of GitHub, but rather Git. I probably got that impression from all of the Go documentation using GitHub as an example (perhaps to seem more familiar to readers). No, I _like_ crates.io because Rust is very explicit that that is where the packages come from. We can get into the benefits and risks and whatever about centralized vs decentralized package managers, but that’s not what I’m talking about. I just want to know how Go does what it does so that I can code confidently in it. A lot of Go packages are specified like so: go get -u github.com/username/repo/version But this is not enforced (you don’t have to specify a version) and this is also not a valid Git repo path and where exactly is this dependency stored and I can go on and on. When you import this package it’s usually import “github.com/user/repo/version/module” But then there is not always a <module> directory in the repo and… you get the idea. This sort of stuff hurts my head and I get it that Go is maybe trying to appear simple but this black box handwavey stuff can and will burn you (this very reason is why the Go community is generally against frameworks) so I just want to have a simple, clear answer and it seems no one else in the Go world has any of these questions. This turns me off. I’m confused by your last bit. Neither Rust nor Go have installation time execution and this is good. I was referring to how you can’t just say “Oh Node has it and this is bad but Go doesn’t and this is good” because Rust doesn’t have it either.