As someone who's been using Go for a long while now, I can't help but wonder if modules and other recent changes aren't a step backwards. Maybe I'm a change-averse geezer, but modules still seem like an overcomplicated solution for a solved problem. Needed a particular version of something? Great. It happens. Add a submodule and toss it in vendor/. Why in God's name do we need to proxy source code through Google-hosted services which they've been reluctant to even open source? And at the root of it all, the GOPATH model simply wasn't bad enough to be worth replacing! You have the full source repo right there, in a predictable, semantically-useful location. When you `go get` something, use `-u`. If a package fails to work with the current upstream, vendor an old version, _or update the depending package_! Ideally, I'd only ever have one copy of source code anywhere on my computer, preferably in the form of revisions in a source repo. Contrary to popular belief, disk space and bandwidth are neither free, nor infinite, and I'd like to make good use of mine. NPM and `node_modules` are NOT designs to aspire to!

If the Go tooling insists on involving itself with versioning, dependencies, and source control, it should actually USE the source control tools to manage versioning and dependencies! It isn't rocket science to make a temp directory, clone from the local repo, check out a tag, and use that for building. Git even has facilities to check out the tree at a specific commit, no full clone required. (Granted, my view is Git-centric, but I believe that mercurial and svn also allow you to clone and check out labelled versions, especially considering those are _the basic requirements_ of an SCM.) And why do we need to verify cryptographic integrity of downloaded code bundles when the SCMs typically use cryptographic primitives to describe versions? Then to mandate a gatekeeping "sum database" on top of all that?

Finally, it is depressing to me how shut-in and closed-off the core team seems. The designs for big language changes are rarely ever proposed by the community, only by people already in the team. While (I hope) the community's input helps inform their decisions, the final module design was rsc's. Before he drafted the design document, dep versioning was a user-space/community problem, but after it came from him, then—and only then—was dependency version management truly considered for the toolchain. The generics design came from, and was accepted by the core team. Rob Pike's recent d̶e̶̶c̶̶i̶̶s̶̶i̶̶o̶̶n̶ proposal to support taking the addresses of simple types is—as one might expect—unquestionably going to be added.

The greatest thing that could happen to Go would be a community-organized and -centric fork, like Gitea was to Gogs. Even if they didn't maintain strict compatibility with each other, I know which one I'd use.