4 ms·

Let's say you write a Go program using a dependency "github.com/foo/bar" v1.0 and post it on the Internet as a regular file (or multiple files), without using g

Let's say you write a Go program using a dependency "github.com/foo/bar" v1.0 and post it on the Internet as a regular file (or multiple files), without using git. Someone else downloads the program and runs the usual Go commands: go mod init example.com/program go mod tidy go build The go tool will see the "github.com/foo/bar" path in the import statements, download the code from the repository, compile and everything will work. Now, let's say the "github.com/foo/bar" module gets a backwards-incompatible change, but does not change the import path, and you attempt to do the above process again. This time, the go tool will download the incompatible version of "github.com/foo/bar" and the build will fail - or even worse, succeed but have some logic bugs that will go unnoticed until some massive shit happens.

masklinn 5y ago
So the Go project used a lazy solution to a hard problem (packages are git repositories without even a ref as version) instead of, say, having an actual versioning scheme, therefore you get to implement this by hand using nonsense logic.
- gowld 5y ago
  There is a versioning scheme. It's not golang's fault if a publisher doesn't use it. https://go.dev/doc/modules/version-numbers https://go.dev/doc/modules/version-numbers
- chabad360 5y ago
  I'm very confused. Go literally uses refs as versions. However to allow for situations where you'll need to update a module because of a bug fix or something like that, Go allows you to safely automatically update to the latest minor version, on the assumption that there are no API breaking changes. If there is such a change, Go wants the module owner to increment the major version so you don't get bugs just from updating. I will agree that the ergonomics of this method aren't perfect by any means. But what it does accomplish, is that it forces you to declare your dependency explicitly (which seems to be one of Go's underlying principles).
- paskozdilar 5y ago
  Actually, Go used a very elegant solution to a hard problem of modularization: directories. A directory == a package. Import path specifies a path to the directory that contains a package. A package may, or may not, decide to have a stable API and document it. If it does, and it commits to the version 1.0, then it basically gives a promise: "This package will not change its API in a way that will break correctness of currently-correct programs that use it". Since a package == a directory, if you want to keep package compatibility, you must not change the contents of the import directory. Therefore, you need to create a new one, preferably called v2/, to put the new code in.
  - tkiolp4 5y ago
    It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy solution: why on earth would I want to specify the version in the path? Git tags solves that problem in a more elegant way (both from the side of the maintainers and users).
    - paskozdilar 5y ago
      > it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.
      - Dylan16807 5y ago

masklinn 5y ago

So the Go project used a lazy solution to a hard problem (packages are git repositories without even a ref as version) instead of, say, having an actual versioning scheme, therefore you get to implement this by hand using nonsense logic.

gowld 5y ago
There is a versioning scheme. It's not golang's fault if a publisher doesn't use it. https://go.dev/doc/modules/version-numbers https://go.dev/doc/modules/version-numbers
chabad360 5y ago
I'm very confused. Go literally uses refs as versions. However to allow for situations where you'll need to update a module because of a bug fix or something like that, Go allows you to safely automatically update to the latest minor version, on the assumption that there are no API breaking changes. If there is such a change, Go wants the module owner to increment the major version so you don't get bugs just from updating. I will agree that the ergonomics of this method aren't perfect by any means. But what it does accomplish, is that it forces you to declare your dependency explicitly (which seems to be one of Go's underlying principles).
paskozdilar 5y ago
Actually, Go used a very elegant solution to a hard problem of modularization: directories. A directory == a package. Import path specifies a path to the directory that contains a package. A package may, or may not, decide to have a stable API and document it. If it does, and it commits to the version 1.0, then it basically gives a promise: "This package will not change its API in a way that will break correctness of currently-correct programs that use it". Since a package == a directory, if you want to keep package compatibility, you must not change the contents of the import directory. Therefore, you need to create a new one, preferably called v2/, to put the new code in.
- tkiolp4 5y ago
  It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy solution: why on earth would I want to specify the version in the path? Git tags solves that problem in a more elegant way (both from the side of the maintainers and users).
  - paskozdilar 5y ago
    > it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.
    - Dylan16807 5y ago