Telemetry in Go

Posted on 15th of February 2023 | 614 words

Update: Go decided to go with opt-in telemetry, which at leastpersonally speaking I’m very happy with. [https://research.swtch.com/telemetry-opt-in](Read more about it from here.)

Last week, Russ Cox from Go team started a discussion about the possibility of starting to collect telemetry from Go usage .

How do software developers understand which parts of their software are being used and whether they are performing as expected? The modern answer is telemetry, which means software sending data to answer those questions back to a collection server.
I believe that open-source software projects need to explore new telemetry designs that help developers get the information they need to work efficiently and effectively, without collecting invasive traces of detailed user activity.
I have written a short series of blog posts about one such design, which I call transparent telemetry, because it collects as little as possible (kilobytes per year from each installation) and then publishes every bit that it collects, for public inspection and analysis.
I’d like to explore using transparent telemetry, or a system like it, in the Go toolchain, which I hope will help Go project developers and users alike. To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by the Go compiler to all Go programs in the world: that’s clearly inappropriate.

Cox also published three part introductory blog post about “transparent telemetry” that is worth a read:

So this whole discussion got me thinking about my feelings towards Go and, possibly, its future. First, I enjoy working with Go. As a language, it’s delightful to work with. It’s safe and fast, and I feel productive in it. But if the Go developers would introduce something like telemetry collecting your Go usage, I would have to re-evaluate the need/desire to use Go in current/new projects. There aren’t many developers that enjoy something like this in their toolchains. Or that would willingly allow something like that.

Sure, collecting telemetry in Visual Studio Code hasn’t affected too much in its popularity. But then again VSCodium is also quite popular, so clearly, some people hate this kind of telemetry, even in their favourite tool. Of course, I’m not yet even talking about the legality of collecting something like that. Because if something like this would be on by default, even if opt-out is offered, looking at GDPR, this can be considered illegal.

Of course, Go has had some “trust issues” for many due to it being language primarily developed, or at least funded, by Google. So naturally, people tend to have certain ideas and feelings about it even without touching it. Understandably so. Many people have already raised criticism in Go, for example, in their usage of Google run closed source Go module proxy mirror (proxy.golang.org), which is set on by default. This is also odd since Go’s import system was made to be decentralized from the get-go. Still, they decided to introduce something like this to increase reliability when importing libraries.

Considering all this, personally, I feel that if they were to introduce something like this to the Go toolchain, especially if it’s set on by default, it’d be a horrible thing for Go making the language to start fighting a big uphill battle, which may never end. I would still like to continue working in it, but if something like this were to happen, I feel that I couldn’t continue working in it if I had a choice.