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

61–70 of 88 posts

Re: Making Go telemetry opt-in is a mistake

#61

Post by MrMcDowall »

majorhelmet wrote: post #56
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…

> Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch. Inbefore I go to a new job and find out that they are using outdated, custom patched go compiler. > I mean, there are 5000+ issues and 330 open PRs on the go github right now How do they know which ones are affecting the most users? > forced google spyware in a compiler go is open source,…

There's a lot of 'just' handwaving here about compiling without telemetry. We just need to look as far as VSCode, which is riddled with unremovable telemetry, and the entire project of VSCodium which has to exist to provide telemetry free versions, and still cannot remove all of it. You're discounting the complete waste of human time and effort required to undo something that should simply not exist in the first place.

In terms of the open GH issues, people are pretty vocal about which ones they think are most important to fix, as is the case for most popular projects. It's simply not true that the Go team have no way of knowing which of the open issues are most important to the community.

Re: Making Go telemetry opt-in is a mistake

#63

Post by croes »

remus wrote: post #13
speedgoose wrote: post #8

Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares. The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.

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

Taking it to the extreme: Would be even better if they know what you write so send the whole code.

It's just a programming language not organ donation.

Re: Making Go telemetry opt-in is a mistake

#64

Post by Brian_K_White »

majorhelmet wrote: post #54
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…

Look, I hate large corps too but this paranoia hinders open source's ability to self-cooperate. > 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. Not true. Even if Google lied about collecting IPs, the data would be sent only every ~ year with aggregated counts so no real time usage data. And even if one could see the patterns…

How is it paranoia to simply propose that Google give us the same thing they want us to give them?

If they don't want to do that, why exactly not?

Paranoia is imagining something. This is posing a question that they or you or anyone is free to simply answer, or fail to.

Re: Making Go telemetry opt-in is a mistake

#65

Post by speedgoose »

xena wrote: post #20
speedgoose wrote: post #16

Earlier quoted context omitted.

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.

Assuming every Go user on the planet fills it out.

They don’t have to care about the super rare cases, and in practice they never did. The survey has already a more than big enough sample to take the right decisions.

Re: Making Go telemetry opt-in is a mistake

#66

Post by speedgoose »

majorhelmet wrote: post #57
speedgoose wrote: post #8

Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares. The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.

Users wishes would be respected in both opt-in and opt-out scenarios.

They really didn’t wish for opt out in the discussions I read.

Re: Making Go telemetry opt-in is a mistake

#67

Post by guipsp »

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…

You say this:

> keep making the damn tool however you want.

But then you follow up with this:

> If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop.

They want to add telemetry. So they should just add it. If you dislike it, then patch it out yourself. As you say:

>That's how open source software is always supposed to work.

Re: Making Go telemetry opt-in is a mistake

#68

Post by fbdab103 »

oplaadpunt wrote: post #22
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…

I really appreciate this point, and I think it applies very broadly. Good design comes from a coherent, individual (or group) vision. Citing examples will only incite discussions, because everyone has a different needs and ideas, but the things I most appreciate in tech and art share this common aspect. As I see it, relying on excessive telemetry, surveys, focus-groups, etc is a bit of an indication that nobody at th…

Which is strange coming from ~Go~ Google. The community loudly demanded features for years which ~Go~ Google said were unnecessary (dependency management, monotonic time, etc). Weird to think that telemetry would do anything to change their opinions when the project has always done what it wants.

Edit: fighting the markup trying to get strikethrough to work

Re: Making Go telemetry opt-in is a mistake

#70

Post by Patrickmi »

Operyl wrote: post #35
fortyseven wrote: post #29

As someone who was considering getting some Go and Rust under his belt, they've saved me a lot of time. This whole telemetry nonsense has ensured I won't waste my time investing it in Go. Great job.

Uh, what? The Go team introduced an idea, opt out telemetry with a one week delay before it was sent. Users said it wasn’t great, overwhelmingly. The Go team heard the feedback and made it opt in. What’s the problem, that’s a good thing.

People are naive, am sure he doesn’t know that rust has telemetry
Post reply on HN