Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Go telemetry opt-in is a mistake

twi.github.io

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Making Go telemetry opt-in is a mistake

#41

Post by remus »

yalue wrote: post #10

Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem…

> keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward.

I disagree, doing what you feel like is a great approach when you have no users, your building a tool that solves your needs and basically saying "Try this it, it works great for me, maybe it'll be good for you too!"

Once you have millions of users and billions of lines of code you need to think about how your changes affect those users. If you get it wrong there's a huge cost to that (c.f. early forays in to go packaging and dependency management). This is why go's comparability promise is such a big deal and a big part of why go is a very popular language.

Re: Making Go telemetry opt-in is a mistake

#42

Post by Kwpolska »

UncleEntity wrote: post #24
remus wrote: post #13

Earlier quoted context omitted.

> For sure it may have a few digits less of accuracy in some dashboards but who cares. You could argue that it's ultimately the users who suffer. Telemetry helps guide development, so it's harder for developers to know what to focus their efforts on.

Reminds me of the whole walrus operator python thing. People were using it, they took it away (IIRC, could be wrong about that), people whined, they brought it back as an explicit operator, people really whined and the BDFL walked away. Telemetry would have told them what exactly?

The walrus operator did not exist before 3.8, there was no real alternative before. The backlash was from people who dislike the idea and would prefer Python didn't add it.

Re: Making Go telemetry opt-in is a mistake

#43

Post by lozenge »

pjc50 wrote: post #5

Reminded of a post I saw the other day referencing Clausewitz to say "if your ideal military strategy is politically unachievable, it's not the ideal strategy". If going for opt-out telemetry makes your customers hate you and you're forced to retreat under a hail of fire, going opt-in is not a mistake. There's also a philosophical problem in going too deep into "customers don't know what they want" and A/B testing ev…

Yes, the author of the article makes the mistake of... not listening to or responding to what the other side thinks, just because she disagrees with them. No concern was addressed in her article.

Re: Making Go telemetry opt-in is a mistake

#44

Post by remus »

speedgoose wrote: post #16
remus wrote: post #13

Earlier quoted context omitted.

> For sure it may have a few digits less of accuracy in some dashboards but who cares. You could argue that it's ultimately the users who suffer. Telemetry helps guide development, so it's harder for developers to know what to focus their efforts on.

But the users can still report issues. And Golang also has the yearly survey that gives much more valuable inputs than telemetry could track IMHO.

> But the users can still report issues.

They can, but do they? Russ' very first blog post gave several examples where major issues slipped under the radar because they went unreported. The example that sticks in my mind is that they accidentally introduced a dependency on a c compiler on Mac that was not reported for over a year simply because users assumed it was meant to be a dependency.

Re: Making Go telemetry opt-in is a mistake

#45

Post by PaulKeeble »

Uvix wrote: post #18
pjc50 wrote: post #5

Reminded of a post I saw the other day referencing Clausewitz to say "if your ideal military strategy is politically unachievable, it's not the ideal strategy". If going for opt-out telemetry makes your customers hate you and you're forced to retreat under a hail of fire, going opt-in is not a mistake. There's also a philosophical problem in going too deep into "customers don't know what they want" and A/B testing ev…

In that scenario, not going opt-out is not a mistake. But going opt-in probably is a mistake, because the data will be useless, so it’s a waste of time to implement.

For those conscious of the security implications of that code even existing it all comes down to whether you trust Google, I would argue at this point you definitely shouldn't. Given that if you program in Go now and have code you really wouldn't just give Google then you probably need to run all your go executions in a VM without network access. This alone is going to be ardious enough from a security point of view to make other languages more interesting.

The entire idea is bad, the defaulting reduces the impact to many but the very existence of this telemetry is enough to take more significant security defence against the tool. Once you start doing that as an organisation Go becomes legacy with a strong desire to replace it. Its definitely a mistake to make it opt in, the data will be lower quality and it will still drive security concerns.

Re: Making Go telemetry opt-in is a mistake

#46

Post by Scubabear68 »

There are vast amounts of Go code available in the wild to study. Open source is a thing.

If the Go team wants to see what features are used, go audit open source Go code.

Since Go is also a Google thing, they could likely audit the presumably large sums of Google Go.

Yes, you will miss unknowable amounts of code this way. Who cares?

Re: Making Go telemetry opt-in is a mistake

#47

Post by b112 »

waweic wrote: post #34

Mozilla shows time and time again that decisions based on opt-out telemetry are worse than decisions taken without telemetry at all. "Telemetry shows people aren't using this (privacy / internet freedom related) feature, so we can just remove it"

While I agree, Mozilla is a horrible example.

There are bugs reports with 100s of people complaining, about simple features, or broken code, and the attitude is WONTFIX.

If you won't listen to users, seething, upset, annoyed over inane issues you created? If you won't fix bugs for years, because it's your pet project/feature?

Then how are you even paying attention to telemetry correctly?

Opt-in telemetry is only useful if you will, no matter what, implement and fix what it tells you. Mozilla, predicated upon their behaviour, clearly only uses data when it agrees with prior opinions.

opt-in is useless to such an org, and opt-out isn't why it is happening.

It's them. They are broken as an org.

Re: Making Go telemetry opt-in is a mistake

#48

Post by UncleEntity »

Kwpolska wrote: post #42
UncleEntity wrote: post #24

Earlier quoted context omitted.

Reminds me of the whole walrus operator python thing. People were using it, they took it away (IIRC, could be wrong about that), people whined, they brought it back as an explicit operator, people really whined and the BDFL walked away. Telemetry would have told them what exactly?

The walrus operator did not exist before 3.8, there was no real alternative before. The backlash was from people who dislike the idea and would prefer Python didn't add it.

The operator didn’t exist but the functionality did. It was just a side effect of python’s wonky variable scoping which they gave an operator.

I’m not familiar with how it works now but the example I remember was the variables escaping from list comprehension statements, like:

  x = [y for y in z]
  if y != z[-1]:
    bad_stuff_happened()
Or something like that, maybe I’m wrong, honestly never had a use for the walrus.

Re: Making Go telemetry opt-in is a mistake

#49

Post by michaelt »

api wrote: post #32
greatgib wrote: post #17

I think that the author has kind of a Stockholm syndrome. "Users are liars, so let's spy them directly to know what we want to know". It is mind blowing how, as an user/the target, you can support that. Nothing is really anonymous and your anonymous data can say a lot about you. Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days. T…

I find the attitude on display here utterly gross and it makes me wonder where this person got it. Is this the common attitude inside Google or Silicon Valley proper these days? Privacy used to be kind of sacrosanct in the industry. What happened? I guess when surveillance driven advertising pays all the bills it has an extreme warping effect on everyone’s mentality. It’s hard to care about privacy when violating it…

> Privacy used to be kind of sacrosanct in the industry. What happened?

It is difficult to get a man to understand something when his salary depends upon his not understanding it.

Re: Making Go telemetry opt-in is a mistake

#50

Post by hedora »

> Developers using macOS are used to just installing Xcode to make the error messages go away, so they just installed Xcode and assumed it was normal behavior.

So, they don’t test go in CI on clean Mac OS installs? If this sort of issue is the rationale for the telemetry system, it sounds like they’re trying for a older, slightly-less-evil Microsoft approach where you fire QA, and just treat user machines as your test environment.

Post reply on HN