Will there be a compile-time option to disable telemetry.
Repositories for binary packages could compile their versions with telemetry disabled.
It's interesting how "tech" companies with billions in cash cannot afford to hire beta testers.
Perhaps the data is collected not only for the purpose of "improving the software". Perhaps the so-called "tech" company, which is actually the world's largest advertising company, wants to use it to make more money. Imagine that.
How would anyone verify that what this employee claims about how telemetry data will be used in the future. Google is a non-transparent company. It's business is advertising. Without that business, there's no money to pay this employee. We know what he wants to improve. His job security and his compensation.
A more truthful statement would be that the data is collected for the purpose of "improving Google's return on advertising". If it isn't, then from a business perspective there is no point in collecting it.
If want voluntary data from users, ask for it. When a "tech" company knows the answer would likely be "no" then they avoid asking for permission. Hence, "enabled by default". Most people do not change default settings.
This is not Go adding telemetry to binaries built with it. Is limited to the Go tooling only. It's good practice to read the announcement. Otherwise you end up making incorrect statements.
Nothing in GP's comment ever even suggests that the Go compiler would insert telemetry into binaries. It's good practice not to put words in people's mouths.
Alternatively, we can remove the new telemetry code by hand before compiling the Go compiler.
Is it still possible to compile the latest Go compiler using the Go 1.14 compiler (C source). Documentation states it is possible but when I tried compiling Go 1.20 with Go 1.14 as the bootstrap I got a message asking for at least Go 1.17.
You'd have to maintain multiple projects to do this completely
- go tool
- gopls
- govulncheck
That's a lot of effort so you can avoid ~1 report per year?
> Based on the sample rates, the Go installation might send a report containing the counter values of interest. Typical sample rates would be around 2% (averaging ~1 report per installation per year), but very rare events could be sampled at a higher rate, up to the 10% limit. As more systems take part in transparent telemetry, the overall sample rate on any given system will decrease, because only a fixed number of samples is necessary.
Telemetry by default ("opt-out") assumes consent by default. That's not how consent works. It's insulting that they're even considering this, and their justifications sound just as condescending as Google's disregard for user privacy.
Very good point. Significant numbers of users, especially over time, would less likely know about the telemetry and to the extent of the data collection. Opt-in (with obvious notice) is clear consent. Opt-out "consent" after the fact, which is made less obvious and after who knows how much was taken, not so much.
In the proposal and blog posts, they estimate that an installation will send on average ~1 report per year, with the expectation that this will decrease over time. They are very open about what information they are and are not collecting. Additionally, they will be making the raw data collected publicly available, so we can all inspect it to see.
I'd be curious to know if another tool which collects metrics is as transparent as the Go team.
And the absence of telemetry data, he contends, makes it more difficult for project maintainers to understand what's important, what's working, and to prioritize changes, thereby making maintainer burnout more likely.
Very funny argument that is often used to attempt to justify telemetry; like if you couldn't just ask and listen to your users to get their feedback instead of spying them. In addition, for that kind of thing, telemetry will not tell you why you see some phenomenon and could lead to negative reinforcement.
You can't necessarily believe what people think they want with a consumer product, sure, but that does not imply that looking at what people do, you know what they need.
That being said, we are speaking here about a population of developers as "free" users. They report bugs or issues that they are encountering. it is not like when you are trying to sell an useless new stuff to random persons...
There are some good examples of why that's not sufficient in Russ' blog post, which is worth reading. They include performance regressions that may not be immediately visible, understanding cache utilization, and better optimizing the toolchain for real-world machine configurations. It's worth reading his article for a better understanding of the goals here:
Such a typical example of someone completely rational, forgetting humans aren’t only about logic. People have emotions, doubts, suspicions, trust issues, affect, all of which aren’t easily quantifiable. The reason people don’t want telemetry in go is simply because of the brand google. That’s just a fact and there’s nothing one can do or say to change that. And yes, forcing it to the users will cripple go to death in a very short time, that’s for sure.
Google brand is what helped the language get traction, also simply because of google having the image of being a tech powerhouse.
That’s life, fighting against this is pointless, i’d suggest rsc to move on to other ideas for getting info on how to improve the language.
VS Code has much more tracking going on, yet it is used by 3/4 developers. If tracking were an issue, you would think this statistic would be very different
There is lots of tools written in Go these days, so this can potentially have wide reaching consequences. Prepare for your friendly docker executable to start shoveling telemetry to Google.
> 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.
sure, it's not in this proposal.
But if telemetry gets added to the compiler, the logical next step is to push it to the next level.
And before you downvote me let me state this: the question is not wether this will happen, but when this will happen.
I think it’s curious that Google announces this so close to their recent layoffs. I wonder if the Go team at Google is looking for additional metrics to justify their existence.
The issue is Go/Google forcing default-on "transparent" telemetry. The only nuance here is that by forcing default-on, a) they get more data, and b) they believe few would opt-in because of the level of trust Google merits.
If people had no reason to mistrust Google, people would opt in. If people would opt-in, they wouldn't bother with "transparent telemetry".
Readit News
Repositories for binary packages could compile their versions with telemetry disabled.
It's interesting how "tech" companies with billions in cash cannot afford to hire beta testers.
Perhaps the data is collected not only for the purpose of "improving the software". Perhaps the so-called "tech" company, which is actually the world's largest advertising company, wants to use it to make more money. Imagine that.
How would anyone verify that what this employee claims about how telemetry data will be used in the future. Google is a non-transparent company. It's business is advertising. Without that business, there's no money to pay this employee. We know what he wants to improve. His job security and his compensation.
A more truthful statement would be that the data is collected for the purpose of "improving Google's return on advertising". If it isn't, then from a business perspective there is no point in collecting it.
If want voluntary data from users, ask for it. When a "tech" company knows the answer would likely be "no" then they avoid asking for permission. Hence, "enabled by default". Most people do not change default settings.
Oh, that sounds like a good idea. Lets do that next!
/s
Is it still possible to compile the latest Go compiler using the Go 1.14 compiler (C source). Documentation states it is possible but when I tried compiling Go 1.20 with Go 1.14 as the bootstrap I got a message asking for at least Go 1.17.
- go tool
- gopls
- govulncheck
That's a lot of effort so you can avoid ~1 report per year?
> Based on the sample rates, the Go installation might send a report containing the counter values of interest. Typical sample rates would be around 2% (averaging ~1 report per installation per year), but very rare events could be sampled at a higher rate, up to the 10% limit. As more systems take part in transparent telemetry, the overall sample rate on any given system will decrease, because only a fixed number of samples is necessary.
Have you read what they are proposing?
I'd be curious to know if another tool which collects metrics is as transparent as the Go team.
You can't necessarily believe what people think they want with a consumer product, sure, but that does not imply that looking at what people do, you know what they need.
That being said, we are speaking here about a population of developers as "free" users. They report bugs or issues that they are encountering. it is not like when you are trying to sell an useless new stuff to random persons...
https://research.swtch.com/telemetry-intro
(Disclosure: I work on developer tools at Google.)
https://research.swtch.com/telemetry-uses
Google brand is what helped the language get traction, also simply because of google having the image of being a tech powerhouse.
That’s life, fighting against this is pointless, i’d suggest rsc to move on to other ideas for getting info on how to improve the language.
Adding tracking to an actual language is unheard of, but can't say I'm surprised Google is trying
It doesn't seem like that is the proposal.
Because you know, they can. And what can you do when your stack is already written in Golang? ..
I strongly recommend readers to read the GitHub issue discussions and Russ Cox's three blog posts.
If people had no reason to mistrust Google, people would opt in. If people would opt-in, they wouldn't bother with "transparent telemetry".
Hoist, meet Petard.
Many developer tools we use daily collect usage data