Very relieved that they chose to back off the initial opt-out proposal. It’s always refreshing to see a language listening to its user base. This was the kind of decision that could instantly change the reputation of a PL, for purely political / psychological reasons.
I think adding telemetry to a compiler goes in the opposite direction of the current "minimal privileges, sandbox all the things" trend.<p>For instance, it would make sense to create a set of selinux rules (or something like it) to make sure that a compiler cannot do anything other than reading its input files (and system headers/libraries/etc) and writing to its output directory, even if for instance a buffer overflow triggered by a malicious source code file led to running shell code within the compiler. Having to allow access to the network for the telemetry would require weakening these rules.<p>It reminds me of the classic "confused deputy" article (<a href="https://css.csail.mit.edu/6.858/2015/readings/confused-deputy.html" rel="nofollow">https://css.csail.mit.edu/6.858/2015/readings/confused-deput...</a>), which coincidentally also involved a compiler tracking statistics about its usage.
Can someone explain how we managed to have programming languages and toolchain development for half a century without using telemetry, but somehow we need it today in our tools? Their Why Telemetry? blog, just doesn't cut it for me [1].<p>[1] <a href="https://research.swtch.com/telemetry-intro" rel="nofollow">https://research.swtch.com/telemetry-intro</a>
I like that they changed their approach to opt-in. I also like how much effort they've put into making the data collection as anonymous as possible despite being a Google project.<p>Well done, golang team. Other companies with supposedly open languages (looking at you, Microsoft) can learn a thing or two from you.
Given how happy people seem to be sending large parts of their codebases to LLMs these days, privacy concerns over telemetry logging look quaint in comparison.
It'll be interesting to see how this is accepted by the community at large. I think explicit opt-in, combined with having the discussion about which metrics to collect in public, would be enough assurance for most that this isn't a <i>bad</i> idea - but doesn't neccesarily mean that most will opt-in as a result.
I'm fairly accustomed now to disabling this shite, but if it's only going to become more prevalent I could see it creating real toil. Are we also going to need a PiHole-like solution for servers and dev boxes?
> IP addresses exposed by the HTTP session that uploads the report are not recorded with the reports.<p>Like pinky promise, trust me bro.<p>This whole thing looks delusional. I hope someone is going to create a fork as Golang team has lost their marbles.
(Maybe I'm just cranky this morning, so please ignore this comment if it fails to please you, but uh... I think the "real WTF" is getting into a position where you need telemetry at all. It's hard to describe what I mean, it seems like most folks who think about these things at all either get it or don't, and the two positions are so self-evident to those that hold them that it blinds us to the rationale of the "other side". In any event, "compiler does not access network" Works For Me. Sorry for the noise.)
Every Problem have a Solution, telemetry is good but abuse of anything is bad, if this follows strictly inline to what they have planned just like what they have been doing, I see no problem. Not everyone must be satisfied
I will be the one overweighted in the report because I keep typing go mod init and go work init...<p>I don't know I never actually remember the commands. :o)
I was one of the more vocal opponents of opt-in telemetry in the original discussion. One thing that seems clear to me coming out of that exchange is that the Go devs are quite anxious to get good-quality data, and are concerned that not enough people will opt in.<p>I for one plan to enable it, and I hope others will do the same.