"Complex chains of dependencies on specific versions" is an anti-pattern, common in the Java world. I am glad that Golang doesn't support or encourage this anti-pattern.

If someone deletes your favorite package, then you can just re-upload it from your cache and let people know about the new URL-- assuming that the code is open source.

If you want to make a backwards-incompatible change in your library, then just create a new version and call it something (slightly) different. There's no reason to complicate things.

I do have some sympathy for this radical simplicity which Go aims for, but at times it comes at a cost, and at times a little bit of complexity has to be added to deal with the real world (only very rarely and after much thought though). I'm torn between admiring that they don't rush into new features and impatience with a few small things they've refused to add so far.

If someone deletes your favorite package, then you can just re-upload it from your cache and let people know about the new URL-- assuming that the code is open source.

Well yes, but then you're de-facto maintainer of that package, you might not have permission to do that, etc - this point though I feel is less important than versioning, it's more an argument for central package control, which has pros and cons. I'd be happy if Go never does that and agree that it can be worked around but will be interested to see if people judge it necessary eventually. There's nothing to stop people setting up a central package resource, and nothing really needs to be added to go to support it.

If you want to make a backwards-incompatible change in your library, then just create a new version and call it something (slightly) different. There's no reason to complicate things.

This is not an acceptable solution, it would lead to situations like:

    import 'github.com/user/yaml_parser'
    import 'github.com/user/new_yaml_parser'
    import 'github.com/user/really_new_yaml_parser'
    import 'github.com/user/toms_new_yaml_parser'

I wouldn't be so quick to defend the status quo - Go is a young language with plenty of maturation still to do, they could easily add versions to packages if it proves necessary - I suspect in the long term it will, because large ecosystems do involve chains of dependencies (I'm not talking about java here, but perl, python, ruby, java, C++, etc all of these languages version libraries in some way), and developers of packages make mistakes which they need to fix, sometimes by deprecating or removing compatibility, but their users don't want to deal with those mistakes, sometimes for years, and the users of their users certainly don't. Choosing a new name and orphaning all your users is not an acceptable solution.

I'd prefer if package maintainers could just do this:

    import 'github.com/user/yaml_parser'
    import 'github.com/user/yaml_parser/1.0'
    import 'github.com/user/yaml_parser/1.0.1'

If you're using a library from github (or wherever) that isn't open source, and someone takes it offline, that's a legal problem, not a technological one. If you are using an open source library, then just re-upload it (or find someone who will). I don't see why the language has to do anything.

What a mess, particular for new users trying to decide which package is best or canonical. Why not just use versions?

You know what a mess is? A mess is:

* In a Maven build, A depends on version 1 of C, A depends on B, B depends on version 2 of C. Result: Java crashes at runtime.

* People using ancient (potentially insecure) versions of Java packages for years because they're afraid of the previous problem.

* "deprecated" functions that continue to be used for years, spewing warnings each time they're referenced.

* a time-consuming bureaucratic process to get your library into some "blessed" central repository.

Go doesn't "support" these messes, and I see no reason why it should.

Perhaps Go's dependency management system will change. I can't tell the future. But so far, I haven't seen any good arguments in favor of changing it. All of the problems you think you're solving with versions could be solved by either maintaining backwards compatibility, or choosing a new package name when you feel you have to break it.