Go is a concurrent, compiled programming language with static typing inspired by C syntax, but with memory safety and garbage collection.
russ cox, a Google software engineer leading the development of the open source programming language Go, presented a possible plan to implement telemetry in the tool chain Go. However, many members of the Go community object because the plan calls for telemetry by default.
These alarmed developers would prefer an opt-in regime over an opt-out regime, a position the Go team rejects because it would ensure low adoption and reduce the amount of telemetry data received to the point where it would be of little value.
For those who don't know about Go, you should know that this is a programming language developed at Google. Although it is similar to the C language, it brings a number of important and modern additions. Russ Cox is the Google engineer currently leading the development of Go, and he has come up with a controversial proposal, which would involve enabling telemetry in Go by default.
Telemetry will cover command line utilities developed by the Go language development team, such as the "go" utility, the compiler, the gopls and govulncheck applications. The collection of information will be limited only to the accumulation of information on the characteristics of public services, i.e. telemetry will not be added to the created applications.
Telemetry, as described by Cox, involves the software sending data from the Go software to a server to provide information about the features being used and how the software is performing. He argues that it is beneficial for open source projects to have this information to guide development.
I believe open source software projects should explore new telemetry designs that help developers get the information they need to work effectively and efficiently, without collecting invasive traces of detailed user activity.
I've written a short series of blog posts about such a design, which I call transparent telemetry, because it collects as little as possible (kilobytes per year from each installation) and then publishes each item it collects, for public inspection and analysis.
I would like to explore the use of transparent telemetry, or a similar system, in the Go toolchain, which I hope will help developers and users of Go projects. To be clear, I'm only suggesting that 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'm not suggesting that the Go compiler add instrumentation to every Go program in the world: that's clearly inappropriate.
Transparent telemetry has the following key properties*:
Although the idea behind the proposal may not be a bad one, the currently planned idea may scare current or potential developers of the Go programming language into any future projects. It should be remembered that most open source developers and users are notoriously opposed to most forms of telemetry.
The reason to collect telemetry, it is the desire to obtain the missing information about the needs and characteristics of the work of developers that cannot be detected using error messages and surveys as a feedback method.
Russ aims to introduce a concept of "transparent telemetry" to help open source projects better understand software while keeping privacy in mind. In his blog posts (a series of 3 articles), he mentions that polls and bug reports are insufficient. Therefore, it is necessary to introduce the easiest way to collect data about the use of an app (ie telemetry) by keeping things open to everyone.
This means that the entire data collection process, how it is processed and what results from it, is open to everyone.
Finally If you are interested in knowing more about it, you can check the details In the following link.
well…to hell with go!.