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.
Perhaps, it may have been a bit of a stretch on my end, but not unfounded given ...
> Repositories for binary packages could compile their versions with telemetry disabled.
... the overall tone of the comment, and peer comments that seem to believe that this is the case. Only GP can confirm their belief to where telemetry would be implemented.
One does not have to "compile with telemetry disabled" but rather disable telemetry with an ENV VAR. It is the "compile" part which has me believe GP believes that this is embedding telemetry in binaries built with Go, which is not what is happening at all.
A runtime option for disabling telemetry has little value for build tools because any random build script can re-enable it without you knowing. Even more so if it's an environment variable for opting out, because it's so common for build scripts to clear environment variables for legitimate reasons.
Whether there's a compile time option to disable telemetry altogether is what many downstream packagers would probably be interested in.
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...
Companies want to refine products to work best for the masses. The problem is the masses do not give feedback or tell you what went wrong. The extreme edge cases do however regularly make themselves heard. When you take your primary feedback from people who chose to give it, you will optimize for edge case users and usually against the desires of the masses.
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
Both MS and Google are evil. Therefore, there is no reason for VS code to enable this tracking; the same goes for Golang and Google. What next? Adblocker/tracker blocker extension for IDEs and compilers?
ms isn't nearly as intrusive as google. I'm using a mac, browse on firefox, but since i'm using google and because of adsense's everywhere they know everything about me.
MS only knows the things i'm typing in vscode. Pretty mild.
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.
Few years back a certain Redmond company shipped C++ compiler update that was producing actual binaries with telemetry. IIRC it got reverted after an outcry.
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".
I have been using Go for almost a decade now, and this is the second time they crossed a line I think they shouldn't have.
The first time was when they introduced the GOPROXY and such. Now `go build` suddenly connects to internet by default, sending package names to Google, unless I explicitly opt-out.
As convenient as it seems to be, I would expect a compiler to not even require network connectivity, and fail loudly if something is missing. It should tell me to download the missing packages myself ("run `go get`" or something), not try to automatically fetch them for me. That's not a compiler's job.
I like Go-the-language, and I'm willing to overlook some inconveniences because I accept the trade-offs, but with this I'll try hard to stop using Go at all unless an alternative working compiler (not gccgo) appears.
There is already a problem with trusting trust[1] as is. If there is any category of software that absolutely must have an immaculate reputation, it would be the software we use to build other software.
People are so convinced of a slippery slope, but I haven’t been able to piece together the plausible evil end game from the comments here. What am I missing?
oh this coward simply locked the discussion to prevent more criticism. why not telemetry on people's response in that thread? you can opt-out the discussion by filtering them in your gmail settings ;)
Mostly memory. Go can run a full web server in 30 mb. Java's equivalent would be around 128 or more. Essentially you can do more PoC on smaller, more affordable hardware using Go. Here's a benchmark for calculation implements. Most of the time Go uses less memory while executing near Java's performance. https://programming-language-benchmarks.vercel.app/go-vs-jav...
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.