This is not a single point of failure. It's by no means a legitimate concern. Go read the proposal. If you don't want to use proxy.golang.org, use goproxy.io. Or host your private one. Fairly sure you'll be able to use github soon as well. Do whatever.
I notice you couldn't back up your FUD about analytics being collected.
Go programmers are happy that they have a solution where their dependencies (and specific versions of those dependencies) will be available forever without them having to take the trouble of vendoring. Your dismissive response? Just vendor. They're happy that clean builds are faster, saving CI time. Your response? It doesn't need to be faster.
You're doing the same thing you're criticising, being dismissive of my concern.
> If you don't want to use proxy.golang.org, use goproxy.io
Yes, I can do that, but as I mentioned in my original post having to get an entire team of people and fleet of CI systems to use a non-standard configuration which is not communiciable in the project repo is a minor PITA.
If and when proxy.golang.org has a bad day, builds will fail. Go developers will have a bad day. Having the ability to work around it doesn't make it not a lynchpin.
As for the "FUD about analytics being collected" it was an offhanded quip. I thought it read pretty clearly as not entirely serious hence the prefix "The cynical side of me feels" and not "I feel". It doesn't merit the effort of defending.
if you read the blog post and the privacy policy, you’d see that they are collecting analytics and requests in logs, including failed private module lookups.
I notice you couldn't back up your FUD about analytics being collected.
Go programmers are happy that they have a solution where their dependencies (and specific versions of those dependencies) will be available forever without them having to take the trouble of vendoring. Your dismissive response? Just vendor. They're happy that clean builds are faster, saving CI time. Your response? It doesn't need to be faster.