Google's Go may add telemetry that's on by default

https://www.theregister.com/2023/02/10/googles_go_programming_language_telemetry_debate/

by mikece • 3 years ago

76 49 3 years ago

theregister.com

filereaper• 3 years ago

This is a nuanced discussion, the linked article may evoke snap responses.

I strongly recommend readers to read the GitHub issue discussions and Russ Cox's three blog posts.

nescioquid• 3 years ago

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".

Hoist, meet Petard.

verdverm8• 3 years ago

If you think this is bad, look at what dotnet collects: https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

Many developer tools we use daily collect usage data

InfamousRece• 3 years ago

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.

patch_cable• 3 years ago

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.

It doesn't seem like that is the proposal.

mvanbaak• 3 years ago

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.

bsaul3• 3 years ago

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.

verdverm8• 3 years ago

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

bsaul3• 3 years ago

Yeap that's my point. Tracking isn't the issue, tracking by google is.

spritefs2• 3 years ago

It's an IDE

Adding tracking to an actual language is unheard of, but can't say I'm surprised Google is trying

cft• 3 years ago

I wonder if they could think of some way to shove ads in the compiler too, it's Google's brainchild after all

1vuio0pswjnm73• 3 years ago

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.

verdverm8• 3 years ago

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.

soraminazuki2• 3 years ago

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.

justinclift• 3 years ago

This is not Go adding telemetry to binaries built with it.

Oh, that sounds like a good idea. Lets do that next!

1vuio0pswjnm73• 3 years ago

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.

verdverm8• 3 years ago

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.

Have you read what they are proposing?

1vuio0pswjnm73• 3 years ago

Telemetry enabled by default is not OK.

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.

greatgib2• 3 years ago

  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.

klyrs• 3 years ago

"I'm stalking you for my mental health?"

timsneath• 3 years ago

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:

https://research.swtch.com/telemetry-intro

(Disclosure: I work on developer tools at Google.)

verdverm8• 3 years ago

The third post is much better for outlining the kinds of questions they hope to answer

https://research.swtch.com/telemetry-uses

Gigachad2• 3 years ago

Because HN users tell you they want a brick phone with a 50,000mah battery and an Ethernet port, and when you release it, they buy the iPhone instead.

stingraycharles• 3 years ago

Yes the age-old lesson that observing users’ behaviour tells a better story than asking them what they want.

greatgib2• 3 years ago

I think that two things are confused here.

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...

barelysapient2• 3 years ago

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.

alunchbox• 3 years ago

Isn't it open source regardless and a lot of the maintainers are not google devs?

barelysapient2• 3 years ago

That’s probably true but it’s being proposed by Russ Cox, a Google executive.

lioeters• 3 years ago

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.

Tozen• 3 years ago

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.

verdverm8• 3 years ago

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.

mihaigalos• 3 years ago

And in the next iteration, Go has telemetry on by default, with no flag to disable it.

Because you know, they can. And what can you do when your stack is already written in Golang? ..

etse2• 3 years ago

Stay on the old version, because you can.

quectophoton• 3 years ago

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.

etse2• 3 years ago

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?

spritefs2• 3 years ago

Why Go and not Java?

This article just makes me more reluctant to ever use it for anything

But if Google wants to ruin their own lang, sure by all means

gadflyinyoureye• 3 years ago

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...

Kim_Bruning• 3 years ago

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.

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

catkitcourt• 3 years ago

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 ;)

Google's Go may add telemetry that's on by default

Related Stories