> Of course, if you simply rely on "go get" then dependency hell is just around the corner when it comes to transient dependencies. A -> C-v1 and A -> B -> C-v1

> Of course, if you simply rely on "go get" then dependency hell is just around the corner when it comes to transient dependencies. A -> C-v1 and A -> B -> C-v1.1. In fact if the entire Go eco-system relied on "go get" there would be no guarantee that a library worked - upstream dependencies could change at any moment. And that's a reason, why go projects should (at least) tag or branch properly. Other projects in other languages do releases, so that you can rest assured that your project works properly with version X of a third party dependency. If a go dependency properly tags or versions its code upstream, you can use that specific tag, which should give you some safety (at least as much as with the traditional release package mechanism in other languages). I do not see a big deal here within the go approach itself. The problem is that many just do not do this properly yet but instead push every change to their main branch, without thinking about the possible impact for consumers of their go packages.