[ameliaquining]

Most code at Google is built in the cloud (https://bazel.build/remote/rbe), with the compiler running in a sandbox that prohibits network access (https://bazel.build/docs/sandboxing). The language server works similarly. So as a technical matter, this kind of telemetry can't work in that environment.

In principle, the Go telemetry could instead be hooked up to a build-system-specific metric reporting system, and the results from that could then be shared with the Go team. A company that uses a Google-style build system could do that kind of integration work if they wanted to contribute their data. But this doesn't make sense for the scenario where the Go compiler is running on some individual dev's machine; there, you want it to upload the data to Google's servers itself.

[jen20]

> you want it to upload the data to Google's servers itself

Google wants that. Maybe even the Go developers want that. It's not remotely clear that users want that.

[ameliaquining]

I mean that that's what's required in order for the telemetry to useful enough to be worth doing at all. If you're against telemetry entirely then of course this isn't going to satisfy you, but then there's no point arguing over the details of how it should work.

[danudey]

Also a lot of CI is "start a VM/container, run the build, save the artefacts, wipe everything", whereas the telemetry data is only uploaded every however often; most CI systems wouldn't collect data for long enough to actually send it before getting wiped anyway.