The Go Team's vehemence to not just have this telemetry as off by default rubs me the wrong way. Sure, that means less people will turn it on... but that's the point. Running telemetry on your machine should not be a requirement for A COMPILER.
Do you want to enable anonymous telemetry? yes [no]
Your choice will be remembered and we won't ask you again.
See our engagements and details on what we collect here: https://go.dev/telemetryI mean, I completely agree with you in principle, but also there are a lot of terrible CI systems out there.
Now the team managing CI (or QA which could actually be in a TTY) needs to notice these failures and communicate them (via a JIRA ticket of course) back to the development team. That team doesn't know what it's about and sticks it on the backlog. Eventually they give the right environment variable, but environment variables are a security risk so it needs to go through security review, and because this mentions telemetry data the privacy and legal teams want sign-off...
This might be an exaggeration, but I think it's worth thinking about the worst case scenario when building things like this into development tools that are used so widely.
If you can't update an environment variable yourself, or ask directly someone who can, all that on a CI system that's somehow bound to TTY, get out of here.
Fixing this in several CI systems I've encountered would take well into months, plausibly with many unknown failures because of cached builds.
> if an environment variable (eg. GO_DISABLE_TELEMETRY=1) is not detected
It could also easily rely on whether the shell is attached to a tty to detect a CI environment, and disable telemetry by default in this case.
Got stats on that? I guess you don't as long as you don't have some kind of telemetry :)
At this point I think it's very hard to say what "most users" do or don't want exactly.
A more reasonable way to go about this would be to launch this as opt-in first, and only bring forward the opt-out proposal if enough people don't opt-in. It doesn't have to go with opt-out on day one. This kind of requirement validation in not uncommon and I would be very surprised if the idea didn't cross them already. It would have been the far easier choice to make especially in the face of strong feedback, but the fact that they just chose to close the discussion instead of trying to move forward on the proposal doesn't bode well.
The way I read that wasn't as a "buzz off, we don't want to discuss this", but rather as a "okay, we've heard all that was said, we will think about it". At some point everything that can be said has been said.
Did they need to close the discussion? Probably not, but it avoids the work and overhead of having to moderate things because it attracted quite a few comments that did need moderation (and will likely continue to attract them).