>Pull in enough dependencies and the chance of a conflict approaches one. Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile.
I'm not sure what you mean by "conflict". That's the nice thing about the way go packages work. There's no v1 of a package and v2 of a package. All packages are different. If one dependency uses foo.v1 and one uses foo.v2 ... they don't conflict. They're as different to go as foo.v1 and bar.v1.
>Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile.
Again, this just doesn't happen. A dependency has one canonical location. If the code changes at that location, it changes for anyone that uses that code. Yes, it's possible this could break only part of your code, if only part of your code was relying on the old behavior/API... but that should be rare (and if it happens, it means you can't trust that third party to stay stable).
I think most people who complain about Go lacking versioning of packages are still stuck in the mindset of pip, npm, etc, where versions are fungible, and your code doesn't know exactly what version it might be working against. This is just not the way Go works. There's one and only one version of a dependency that your project sees. Anyone using that dependency uses the same version. If the dependency's code compiles on its own, it'll compile on your machine, too.
There is nothing in Go that prevents people from making breaking changes to a package - and therefore breaking changes happen. I'll trust my real-world observations of broken dependencies over your assertion that they can't happen.
My point is if you're not tracking the version of your dependencies, it can be hard to even know what versions to go back to to get something that compiles. It may not be enough to just roll back the package with the breaking change, since you may have other dependencies that have been updated to depend on the new version.
The only way to reliably be able to compile your program in the future is to record the exact versions of all your dependencies.
I'm not sure what you mean by "conflict". That's the nice thing about the way go packages work. There's no v1 of a package and v2 of a package. All packages are different. If one dependency uses foo.v1 and one uses foo.v2 ... they don't conflict. They're as different to go as foo.v1 and bar.v1.
>Some of your dependencies will get updated and some of them won't, and soon enough you'll have a hard time finding any combination of versions that will compile.
Again, this just doesn't happen. A dependency has one canonical location. If the code changes at that location, it changes for anyone that uses that code. Yes, it's possible this could break only part of your code, if only part of your code was relying on the old behavior/API... but that should be rare (and if it happens, it means you can't trust that third party to stay stable).
I think most people who complain about Go lacking versioning of packages are still stuck in the mindset of pip, npm, etc, where versions are fungible, and your code doesn't know exactly what version it might be working against. This is just not the way Go works. There's one and only one version of a dependency that your project sees. Anyone using that dependency uses the same version. If the dependency's code compiles on its own, it'll compile on your machine, too.