> How do software developers understand which parts of their software are being used and whether they are performing as expected?
By asking nicely. Not by siphoning data out of my system.
Where is this world going ? Do i really have to treat every program as spyware and restrict its internet access ? And anyway, why would a compiler need internet access ?
Asking nicely doesn't work in pratice because people willing to answer the question is not a randomly sampled group of people and usually highly biased. You can check how polling works and why it doesn't work.
The problem is always how to randomly sample people and AFAIK there is no good way except randomly sample people (a.k.a telemetry). You can argue that developers shouldn't care that much about their software are being used and whether they are performing as expected, but asking nicely really is not a solution.
APPENDED: PLEASE NOTE I'm saying asking nicely is not a solution to get correct data from statistical standpoint. You can argure the data accuracy is not important in this context.
The world was already there, your bubble just burst. In recent decades tech companies and their programmers have done everything they can to collect data about users. Are you now surprised that the same companies apply the same practices for technical users of their software?
The solution, at least for me, is to remove that software from my life. Personally I vowed a long time ago to never work for a company whose business is to track people. It's no big deal for me, but I understand at least some may have hard decisions to make.
> Do i really have to treat every program as spyware and restrict its internet access ?
My feeling about Google is that they do not respect privacy, no matter the product. Invasion of privacy and tracking their customers are behaviors deeply ingrained in Google DNA.
Doing so for all other products has been incredibly profitable, so why not Go? It’s not like Go the language has a history of respecting the PL community (the resolution of Google stepping on the Go name was Google throwing their weight around and told the Go! author to pound sand), so why should anyone expect they respect their users?
> Do i really have to treat every program as spyware and restrict its internet access ?
If you're using an application from Google or Microsoft or any big tech company for that matter: yes.
> And anyway, why would a compiler need internet access ?
The go build tool will fetch dependencies for you. If you don't use dependencies or use a local network proxy instead of the Google one you can safely disable WAN access, but otherwise you'll end up with a broken tool.
It doesn't. It compiles without internet access. If it has internet access it can also send telemetry data. If the compiler refused to work in all cases where it couldn't send telemetry data, I'd see the point...
Somehow we managed to create very high quality software before all this telemetry being larded all over every single thing.
Languages like Go have enormous test code bases with unit tests to ensure that every corner of the language is compiled and executes correctly. We don't need gobs of telemetry to phone home about how people are using a compiler.
>By asking nicely. Not by siphoning data out of my system.
THIS !!!
I suspect like many people, I feel that if they had said "We're going to introduce this ... but don't worry, it will be opt-in", then they would have avoided 99.99999999999999% of the negativity.
Instead, by making it opt-out, they are basically doing a classic Google shit move.
And that's before we start getting into questions about GDPR and opt-out.
Yeah fwiw I am strongly opposed to the proposal, and Russ Cox acknowledged that they considered many of the posts against telemetry or for opt in only as valid discussion, and gave examples of some of the inappropriate comments they referred to as being in "bad faith". I appreciated his clarity there in answering about what he considered bad faith posts.
There were definitely comments that got quite heated and probably fell outside good discourse practices, largely because people are very passionate about privacy and also tend to get very upset when they feel betrayed.
I mean, some folks in the thread were absolutely arguing in bad faith.
A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry in general without even taking a look at the actual proposal[0] (which has some important points regarding collection frequency, data shared, and architecture). Not saying there should be no critique, but blanket statements that often criticize aspects that are irrelevant here don't help.
They're really trying to approach this in a way that, to me, is as reasonable and transparent as effectively possible (yes, I'm on the side of "opt-in telemetry doesn't work because of the majority of people who don't care either way; won't turn off if prompted, won't turn on either", so being opt-in is in fact unreasonable to me).
The Go toolchain already in a sense "calls home" by default to the Go module proxy hosted by Google.
Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it. Telemetry is immensely useful to understand what features or technical improvements are worth prioritizing to benefit the actual average user the most, and not just the vocal minority. Telemetry being opt-in breaks this by once again prioritizing the vocal minority that turns it on.
> I mean, some folks in the thread were absolutely arguing in bad faith. A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry in general without even taking a look at the actual proposal
It is still telemetry, other platform's toolchains dont have it, it's not bad faith for rejecting it.
> Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it.
> The Go toolchain already calls home by default to the Go module proxy hosted by Google.
I don't think it's fair to describe the Go proxy as "calls home"; no one says that about Rubygems, PyPI, npm, or any other package tool. If anything, the Go proxy is the only package system that actually allows disabling it quite easily and pain-free. Try using Ruby without rubygems or React without npm: no doubt possible, but it will take a lot more effort.
Opt-in telemetry not executing for users who would like it to be executing, because they don't know about it or forgot, makes it an under-advertised feature.
Opt-out telemetry executing for users who would not like it to be executing, because they don't know about it or forgot, makes it a spyware.
The rest of the discussion only makes sense to have if you agree there are circumstances when implementing spyware is justified.
The Go Team's vehemence to not just have this telemetry as off by default rubs me the wrong way. Sure, that means less people will turn it on... but that's the point. Running telemetry on your machine should not be a requirement for A COMPILER.
It could even just be a prompt at first use, if an environment variable (eg. GO_DISABLE_TELEMETRY=1) is not detected. Example:
Do you want to enable anonymous telemetry? yes [no]
Your choice will be remembered and we won't ask you again.
See our engagements and details on what we collect here: https://go.dev/telemetry
It's not a requirement. Something being "a requirement" would mean that it didn't actually work (compile) without it switched on. That's not the case. It's not required for the program to function and it's not required by the license. So it's not required in any way at all.
Even more so when they claim they don't need to sample more than 16000 reports! Like dude, you can easily find 16000 opting in across millions of users . Hell, if everyone in Google opts in, that is more than a sufficient sample. It's really a non-issue if you consider their problem statement. The fact that they are so adamant in the face of substantial feedback makes me think if there is some other ulterior motive at play.
I think a compiler that phones home is a great addition to my AI-powered terminal (https://www.warp.dev) and toaster with a camera that I never changed the default password on. /s
So, is it time to fork the go codebase and have a telemetry-free version?
I understand that there are uses for such data to help make the tooling better.
I don't understand how Google and its cult can be so disingenuously surprised that people are wary of it in 2023. This makes me trust them even less than normal - i suspect they'll follow the MS playbook and "accidentally" make the opt-out fail and eventually the idea of opt-out will be completely removed from the product because "everyone seems to be happy with it... No one turns it off anyway".
I see a lot of pro-opt-in arguments along the lines of "it needs to be opt-in by default, because the people we'd like to know from won't bother opting in, but wouldn't care either way".
Whilst I wouldn't argument that's an inaccurate description of the people you want data from, counter point: tough?
We're used to these liberties being taken in IT, so let's imagine a less technical scenario. You buy some lightbulbs from ShopX, and they'd really like to know your lightbulb usage habits in order to improve the efficiency of their lightbulbs (and nothing else, honest guv! but okay, let's give them the benefit of the doubt).
They could send you a questionnaire, and as rightly pointed out in these arguments, it's unlikely you'd bother with it. Or they could ... what?
Anything that involves them getting that information is a slippery slope at best, and a bit creepy already. This is the only industry where we've normalised this kind of liberty taking.
> This is the only industry where we've normalised this kind of liberty taking.
Or the only one where you're personally aware of it. The kind of low-frequency limited data the Go team proposed collecting is basically the same as, say, McDonald's telling store managers to report how many people ordered mayonnaise on their sandwiches so they can decide whether to continue stocking it. It's worlds better than the kind of individual patron tracking large retailers or credit card companies routinely do, but they don't advertise that.
There are two differences here: one is where data collection happens — since this is running locally rather than in the cloud we know it's happening — and the other is the larger question of Google's corporate reputation is affecting reactions. A lot of the takes on social media have been reacting to that larger issue, many by people who don't even use Go, and are alleging scenarios far beyond what would be possible with the proposed system. I think some of this also goes back to the risk of being open: I would bet that more than a few of the people who are very concerned about Go lang use tools like VSCode which collect far more data but not having the big public proposal didn't mean everyone was talking about it at the same time.
As one of the commenters in the original GitHub discussion pointed out, the package managers of most open source operating systems ultimately will/should package Go with telemetry turned off by default, regardless of the Go project’s default behavior.
Good luck getting non-operating system biased data after that.
Collecting non-operating system biased data seemed to be one of the stated goals to making the telemetry turned on by default. Otherwise it was posited that Go users on open source operating systems would disproportionately choose to keep telemetry off when prompted in an opt-in model.
Leaving the (probably incorrect?) claim of suppression in the title aside for a moment, I just want to express my deep sadness about this decision.
I'm an ex-Googler who has admired Golang for many years and have been considering it for use in my hardware startup.
The fact that opt-out-only telemetry was even considered, much less appears to be already decided(?), makes me far less likely to use this tool chain at any time in the future.
> I think it's pretty obvious that opt out telemetry rubs most people the wrong way.
This is basically re-stating the opt-in challenge: we know that some people are vocally upset by it but we have to guess at the relative percentages of the groups of people who know and do not mind, don't know but would be upset, or don't know and wouldn't mind if they did. People who are upset are far more motivated to comment about it, so anyone looking at social media is going to see a lot of messages from them but still not know what percentage of the total community feels similarly. I've even seen people who aren't primarily in the Go community but very active on privacy issues commenting on this, which is perfectly legitimate but also not representative of the median Go developer.
DNS isn't enough, applications have been sneaking off data to hard-coded IPs and through other means for at least 15 years now. These days we have DoH as a standard, but way before that I spotted a Windows application execute HTTP requests to resolve IP addresses for their tracking domain.
With some effort you can MitM your phone with your own certificate authority and a tool like mitmproxy in transparent mode. It still won't detect all of the trackers (detecting MitM is quite easy with certificate pinning), but it'll show you even clearer how much you're being tracked.
Expect every API to also be a tracking endpoint, and expect every application you use to upload your location. There are apps that do well, but they've become the exception rather than the rule.
Especially with so much interest and momentum seeming to have shifted to Rust of late, I wonder whether Golang support is on or near Google's famously bloody chopping block, and adding analytics would help support a "data-driven" case for keeping it funded.
I don't understand why people insist on comparing Go and Rust, when they clearly don't compete against each other. Rust competes with C++, Go competes with Java. The only thing they have in common is being relatively modern and recent languages, but they just don't share the same goals and don't have the same promises.
[+] [-] hulitu|3 years ago|reply
By asking nicely. Not by siphoning data out of my system.
Where is this world going ? Do i really have to treat every program as spyware and restrict its internet access ? And anyway, why would a compiler need internet access ?
[+] [-] fancl20|3 years ago|reply
The problem is always how to randomly sample people and AFAIK there is no good way except randomly sample people (a.k.a telemetry). You can argue that developers shouldn't care that much about their software are being used and whether they are performing as expected, but asking nicely really is not a solution.
APPENDED: PLEASE NOTE I'm saying asking nicely is not a solution to get correct data from statistical standpoint. You can argure the data accuracy is not important in this context.
[+] [-] creepycrawler|3 years ago|reply
The solution, at least for me, is to remove that software from my life. Personally I vowed a long time ago to never work for a company whose business is to track people. It's no big deal for me, but I understand at least some may have hard decisions to make.
[+] [-] pabs3|3 years ago|reply
https://wiki.debian.org/PrivacyIssues https://www.qubes-os.org/
[+] [-] ModernMech|3 years ago|reply
My feeling about Google is that they do not respect privacy, no matter the product. Invasion of privacy and tracking their customers are behaviors deeply ingrained in Google DNA.
Doing so for all other products has been incredibly profitable, so why not Go? It’s not like Go the language has a history of respecting the PL community (the resolution of Google stepping on the Go name was Google throwing their weight around and told the Go! author to pound sand), so why should anyone expect they respect their users?
[+] [-] jeroenhd|3 years ago|reply
If you're using an application from Google or Microsoft or any big tech company for that matter: yes.
> And anyway, why would a compiler need internet access ?
The go build tool will fetch dependencies for you. If you don't use dependencies or use a local network proxy instead of the Google one you can safely disable WAN access, but otherwise you'll end up with a broken tool.
[+] [-] alkonaut|3 years ago|reply
It doesn't. It compiles without internet access. If it has internet access it can also send telemetry data. If the compiler refused to work in all cases where it couldn't send telemetry data, I'd see the point...
[+] [-] api|3 years ago|reply
Languages like Go have enormous test code bases with unit tests to ensure that every corner of the language is compiled and executes correctly. We don't need gobs of telemetry to phone home about how people are using a compiler.
[+] [-] threatofrain|3 years ago|reply
[+] [-] oweiler|3 years ago|reply
[+] [-] traceroute66|3 years ago|reply
THIS !!!
I suspect like many people, I feel that if they had said "We're going to introduce this ... but don't worry, it will be opt-in", then they would have avoided 99.99999999999999% of the negativity.
Instead, by making it opt-out, they are basically doing a classic Google shit move.
And that's before we start getting into questions about GDPR and opt-out.
[+] [-] arp242|3 years ago|reply
The insinuation that all comments opposing the telemetry are hidden is bullshit, as a simple check will confirm: https://github.com/golang/go/discussions/58409
[+] [-] ocdtrekkie|3 years ago|reply
There were definitely comments that got quite heated and probably fell outside good discourse practices, largely because people are very passionate about privacy and also tend to get very upset when they feel betrayed.
[+] [-] yencabulator|3 years ago|reply
Well, mine were, and I don't think I was rude, pithy, or repetitive. So your calling it bullshit is, frankly, bullshit.
Hiding "I don't want this" comments also conveniently completely hides their vote counts, absolutely suppressing people's opinions.
[+] [-] cube2222|3 years ago|reply
A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry in general without even taking a look at the actual proposal[0] (which has some important points regarding collection frequency, data shared, and architecture). Not saying there should be no critique, but blanket statements that often criticize aspects that are irrelevant here don't help.
They're really trying to approach this in a way that, to me, is as reasonable and transparent as effectively possible (yes, I'm on the side of "opt-in telemetry doesn't work because of the majority of people who don't care either way; won't turn off if prompted, won't turn on either", so being opt-in is in fact unreasonable to me).
The Go toolchain already in a sense "calls home" by default to the Go module proxy hosted by Google.
Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it. Telemetry is immensely useful to understand what features or technical improvements are worth prioritizing to benefit the actual average user the most, and not just the vocal minority. Telemetry being opt-in breaks this by once again prioritizing the vocal minority that turns it on.
[0]: https://research.swtch.com/telemetry-intro
[+] [-] the_gipsy|3 years ago|reply
It is still telemetry, other platform's toolchains dont have it, it's not bad faith for rejecting it.
> Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it.
Yea, so Rust it is then.
[+] [-] arp242|3 years ago|reply
I don't think it's fair to describe the Go proxy as "calls home"; no one says that about Rubygems, PyPI, npm, or any other package tool. If anything, the Go proxy is the only package system that actually allows disabling it quite easily and pain-free. Try using Ruby without rubygems or React without npm: no doubt possible, but it will take a lot more effort.
[+] [-] somethingreen|3 years ago|reply
Opt-out telemetry executing for users who would not like it to be executing, because they don't know about it or forgot, makes it a spyware.
The rest of the discussion only makes sense to have if you agree there are circumstances when implementing spyware is justified.
[+] [-] John23832|3 years ago|reply
[+] [-] thiht|3 years ago|reply
[+] [-] dx034|3 years ago|reply
[+] [-] alkonaut|3 years ago|reply
[+] [-] potamic|3 years ago|reply
[+] [-] Xeoncross|3 years ago|reply
[+] [-] sophacles|3 years ago|reply
I understand that there are uses for such data to help make the tooling better.
I don't understand how Google and its cult can be so disingenuously surprised that people are wary of it in 2023. This makes me trust them even less than normal - i suspect they'll follow the MS playbook and "accidentally" make the opt-out fail and eventually the idea of opt-out will be completely removed from the product because "everyone seems to be happy with it... No one turns it off anyway".
[+] [-] ghusto|3 years ago|reply
Whilst I wouldn't argument that's an inaccurate description of the people you want data from, counter point: tough?
We're used to these liberties being taken in IT, so let's imagine a less technical scenario. You buy some lightbulbs from ShopX, and they'd really like to know your lightbulb usage habits in order to improve the efficiency of their lightbulbs (and nothing else, honest guv! but okay, let's give them the benefit of the doubt).
They could send you a questionnaire, and as rightly pointed out in these arguments, it's unlikely you'd bother with it. Or they could ... what?
Anything that involves them getting that information is a slippery slope at best, and a bit creepy already. This is the only industry where we've normalised this kind of liberty taking.
[+] [-] acdha|3 years ago|reply
Or the only one where you're personally aware of it. The kind of low-frequency limited data the Go team proposed collecting is basically the same as, say, McDonald's telling store managers to report how many people ordered mayonnaise on their sandwiches so they can decide whether to continue stocking it. It's worlds better than the kind of individual patron tracking large retailers or credit card companies routinely do, but they don't advertise that.
There are two differences here: one is where data collection happens — since this is running locally rather than in the cloud we know it's happening — and the other is the larger question of Google's corporate reputation is affecting reactions. A lot of the takes on social media have been reacting to that larger issue, many by people who don't even use Go, and are alleging scenarios far beyond what would be possible with the proposed system. I think some of this also goes back to the risk of being open: I would bet that more than a few of the people who are very concerned about Go lang use tools like VSCode which collect far more data but not having the big public proposal didn't mean everyone was talking about it at the same time.
[+] [-] nishs|3 years ago|reply
Good luck getting non-operating system biased data after that.
Collecting non-operating system biased data seemed to be one of the stated goals to making the telemetry turned on by default. Otherwise it was posited that Go users on open source operating systems would disproportionately choose to keep telemetry off when prompted in an opt-in model.
[+] [-] lbayes|3 years ago|reply
I'm an ex-Googler who has admired Golang for many years and have been considering it for use in my hardware startup.
The fact that opt-out-only telemetry was even considered, much less appears to be already decided(?), makes me far less likely to use this tool chain at any time in the future.
[+] [-] arp242|3 years ago|reply
[+] [-] gregors|3 years ago|reply
https://code.visualstudio.com/docs/getstarted/telemetry
https://stackoverflow.com/questions/64570113/how-do-i-stop-n...
I think it's pretty obvious that opt out telemetry rubs most people the wrong way.
[+] [-] acdha|3 years ago|reply
This is basically re-stating the opt-in challenge: we know that some people are vocally upset by it but we have to guess at the relative percentages of the groups of people who know and do not mind, don't know but would be upset, or don't know and wouldn't mind if they did. People who are upset are far more motivated to comment about it, so anyone looking at social media is going to see a lot of messages from them but still not know what percentage of the total community feels similarly. I've even seen people who aren't primarily in the Go community but very active on privacy issues commenting on this, which is perfectly legitimate but also not representative of the median Go developer.
[+] [-] deafpolygon|3 years ago|reply
Does a singular setting actually turn off telemetry in VS Code? (aside from Extensions telemetry)
[+] [-] thejosh|3 years ago|reply
If you really want to see what your devices send back, monitor DNS on your devices.
I installed a bunch of apps on a spare phone (that had no sim card) and was VERY surprised how much background data and requests Tiktok used.
[+] [-] jeroenhd|3 years ago|reply
With some effort you can MitM your phone with your own certificate authority and a tool like mitmproxy in transparent mode. It still won't detect all of the trackers (detecting MitM is quite easy with certificate pinning), but it'll show you even clearer how much you're being tracked.
Expect every API to also be a tracking endpoint, and expect every application you use to upload your location. There are apps that do well, but they've become the exception rather than the rule.
[+] [-] tom-thistime|3 years ago|reply
The answer is No. No telemetry to be used on people who don't want it.
[+] [-] throwanem|3 years ago|reply
[+] [-] thiht|3 years ago|reply
[+] [-] pabs3|3 years ago|reply
[+] [-] deafpolygon|3 years ago|reply
Once allow Go in Debian, then what? More packages with telemetry turned on becoming the "norm" and accepted? No.
[+] [-] WhyNotHugo|3 years ago|reply
Google/Golang devs: You're objecting in bad faith and violating our Code of Conduct.
[+] [-] r0ckysharma|3 years ago|reply
telemetry is definitely not a solution half of the industry would be happy about. It's polite way of saying - I want to know what you are doing!
[+] [-] gtirloni|3 years ago|reply
On the other, you have to possibly learn a new language, tools, libraries, etc, new community, new release cadence, different feature set, etc.
Tough choice.
[+] [-] _aaed|3 years ago|reply
[+] [-] WesolyKubeczek|3 years ago|reply
[+] [-] typical182|3 years ago|reply
https://news.ycombinator.com/item?id=34754632
[+] [-] Clent|3 years ago|reply
Apple does this same thing with an opt-in. Google is evil. Stop supporting evil.
[+] [-] jensensbutton|3 years ago|reply
[+] [-] aejnsn|3 years ago|reply
Stupid proposal. If I wanted telemetry, I’d implement with a trusted party, whose service I am paying to use.
[+] [-] zajio1am|3 years ago|reply