Go Compiler Telemetry
Russ Cox, a Google software engineer steering the development of the open source Go programming language, has presented a possible plan to implement telemetry in the Go toolchain.
However many in the Go community object because the plan calls for telemetry by default.
[…]
Cox’s proposal summarized lengthier documentation in three blog posts.
This post is about why I believe telemetry is important for open-source projects, and what it might look like to approach telemetry in an open-source-friendly way. That leads to a new design I call transparent telemetry.
[…]
Statistics gathered by transparent telemetry make it possible for developers to notice that something is going wrong even when users do not.
For example, during the Go 1.14 release process in early 2020 we made a change to the way macOS Go distributions are built, as part of keeping them acceptable to Apple’s signing tools. Unfortunately, the way we made the change also made all the pre-compiled
.afiles shipped in the distribution appear stale to builds. […] No one reported the bug over three years of Go releases. We didn’t notice and fix the problem until late 2022 while investigating something else.[…]
Some open-source projects have adopted traditional telemetry, with mixed success and varying levels of user pushback. For example: Audacity, GitLab, and Homebrew. Homebrew’s telemetry seems to be generally accepted by users, and VS Code’s detailed telemetry has not stopped it from being used by 74% of developers, as reported by the 2022 StackOverflow survey.
- Counting: Go toolchain programs store counter values in per-week files maintained locally.
- Configuration: There is a reviewed public process for defining a new graph or metric to track and publish on the Go web site. The exact counters that need to be collected, along with the sampling rate needed for high accuracy results, are derived from this configuration.
- Reporting: Once a week, an automated reporting program randomly decides whether to fetch the current configuration and then whether to be one of the sampled systems that week. If so, it reports the counters listed in the configuration to a server run by the Go team at Google. In typical usage, we expect a particular Go installation to report each week with under 2% probability, meaning less than once per year on average.
- Publishing: The server publishes each day’s reports in full (in a compressed form) as well as publishing the tabular and graphical summaries defined in the configuration.
Understanding how often GOPATH mode (non-module mode) is used is important for understanding how important it is to keep running, and for which use cases.
[…]
David Gerard (via Hacker News):
the Go maintainers are now claiming that objectors to Google’s opt-out telemetry proposal on the Go compiler - yes, really - are arguing in bad faith and violating the Code of Conduct, and their comments are getting hidden.
The current plan is to use some form of opt-in to collect telemetry.
[…]
As mentioned in the introductory post,
-buildmode=sharedhas never worked particularly well, and its current design is essentially incompatible with Go modules. We have a rough design for how we might make it work, but that’s a lot of work, and it’s unclear whether it should be a high priority. Our guess is that there are essentially no users of this flag, and that therefore it shouldn’t be prioritized. But that’s just a guess; data would be better.[…]
The Go build cache is a critical part of the user experience, but we don’t know how well it works in practice. The original build cache heuristics were decided in 2017 based on a tracing facility that we asked users to run for a few weeks and submit traces. Since then, many things about Go builds have changed, and we have no idea how well things are working.
See also: Dropbox (via Hacker News).
Previously:
Update (2023-05-17): Russ Cox (via Hacker News):
No change in consensus, so accepted. 🎉
