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

Go 1.23 Released

go.dev

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Go 1.23 Released

#71

Post by slowmovintarget »

rkharsan64 wrote: post #39
hu3 wrote: post #3

Opt-in telemetry. A very rare sight these days. Glad to see. Not even Mozilla does that with Firefox [1]. > Starting in Go 1.23, the Go toolchain can collect usage and breakage statistics that help the Go team understand how the Go toolchain is used and how well it is working. We refer to these statistics as Go telemetry. > Go telemetry is an opt-in system, controlled by the go telemetry command. By default, the tool…

It seems like the right way to respect a user's privacy, but opt-in telemetry just doesn't work. I see the concerns as a user (and disable telemetry wherever I can), but at the same time if I were to add telemetry to my OSS project, I would either make it opt out, or just not add it at all. The people who actually enable telemetry are a huge minority, and the data collected would be completely useless due to bias. Th…

> The best way...

The best way is not to have telemetry at all. But then that's a user-centric take.

Re: Go 1.23 Released

#72

Post by [deleted] »

bananapub wrote: post #69
traceroute66 wrote: post #40

Earlier quoted context omitted.

> Opt-in telemetry. A very rare sight these days. Glad to see. Ahem. Cough. Given Google's ties to Go, of course it was NOT opt-in when originally announced. After, shall we say, a "lively" discussion on the relevant Github topic[1], it was changed to opt-in. :D Opt-in is the correct stance. [1] https://github.com/golang/go/discussions/58409

there's infinity things to criticise google for, but "the go team want useful metrics" isn't one of them.

[deleted]

Re: Go 1.23 Released

#73

Post by frosting1337 »

traceroute66 wrote: post #40
hu3 wrote: post #3

Opt-in telemetry. A very rare sight these days. Glad to see. Not even Mozilla does that with Firefox [1]. > Starting in Go 1.23, the Go toolchain can collect usage and breakage statistics that help the Go team understand how the Go toolchain is used and how well it is working. We refer to these statistics as Go telemetry. > Go telemetry is an opt-in system, controlled by the go telemetry command. By default, the tool…

> Opt-in telemetry. A very rare sight these days. Glad to see. Ahem. Cough. Given Google's ties to Go, of course it was NOT opt-in when originally announced. After, shall we say, a "lively" discussion on the relevant Github topic[1], it was changed to opt-in. :D Opt-in is the correct stance. [1] https://github.com/golang/go/discussions/58409

But it is now, and that's good and should be applauded.

Re: Go 1.23 Released

#74

Post by etse »

traceroute66 wrote: post #41
minkles wrote: post #17

> Go telemetry is an opt-in system Great job Go. Hat tip and respect for this. Unlike .Net. I will enable this where it is appropriate.

> Great job Go. Hat tip and respect for this Whoah. Easy there cowboy. It was not opt-in when originally announced. After an extended, shall we say, "lively" discussion on Github[1], they did the right thing and made it opt-in. (N.B. The discussion was heavily moderated and redacted, it was even more "lively" at the time.) [1] https://github.com/golang/go/discussions/58409

Are you opposed to the process by which discussion can initiate a transition from negative state to positive state?

Seems healthy to me.

Re: Go 1.23 Released

#75

Post by arp242 »

0cf8612b2e1e wrote: post #67
wsve wrote: post #29

Earlier quoted context omitted.

I'm open to being convinced otherwise, but I feel like I'm the only one who doesn't get why opt-out telemetry is such a big deal. Sure, if it's a software library, I don't want it doing random network calls during my runtime. That's just rude. But if it's a user application (including a compiler), I don't see what the fuss is about. Of all the myriad of ways our data is harvested every single day, telemetry seems ver…

You don’t know what they are sending. Maybe today it is innocuous data. Tomorrow, they ship off your ssh keys. Better to default deny all.

A program that does not connect to the network at all today can also start shipping off your ssh keys tomorrow. Anything can always be added or changed.

Re: Go 1.23 Released

#76

Post by unscaled »

fourseventy wrote: post #35
icholy wrote: post #24

Earlier quoted context omitted.

The change adds no syntax.

"for key, val := range m.Range" is syntactic sugar for using the m.Range iterator directly "m.Range(func(key, val any) bool". In a vacuum I think it's fine, but I don't want to see stuff like this getting added to the language routinely. I prefer a small language.

Go grew too big (in popularity) to be small. Popular languages tend to grow as the userbase grows. This is natural — the language gets used across a wider range of industries, and the programs being written in the language become larger, more mature and more diverse.

The language maintainers need to balance a small specification or a small implementation versus the users' demand, but in most cases at least some user demands win routinely. This is especially true when the language has just one major implementation. There is a significant cost for making that implementation more complex, but there is a more significant cost for making millions of programs that rely on a single implementation more complex just to make that implementation simpler.

Re: Go 1.23 Released

#77

Post by wsve »

kingsleyopara wrote: post #54
wsve wrote: post #29

Earlier quoted context omitted.

I'm open to being convinced otherwise, but I feel like I'm the only one who doesn't get why opt-out telemetry is such a big deal. Sure, if it's a software library, I don't want it doing random network calls during my runtime. That's just rude. But if it's a user application (including a compiler), I don't see what the fuss is about. Of all the myriad of ways our data is harvested every single day, telemetry seems ver…

Privacy concerns aside, I personally don't appreciate binaries making network requests unless it's strictly required for them to function.

Where is that line for you? Is occasionally checking for security updates strictly necessary? Is reporting a crash to the devs so they can fix it necessary? What about sending system & usage telemetry so they can prevent future bugs?

Re: Go 1.23 Released

#78

Post by peterashford »

bartonfink wrote: post #70
mariusor wrote: post #56

Earlier quoted context omitted.

> You put your cursor on the "Range" portion of m.Range, and hit "Jump to Definition". Well, that's one reason why people usually run away from languages high in magic like Java/JS to something like Go: not needing a fancy IDE to make sense of what's happening with a single line of code.

[flagged]

Unnecessarily agressive

Re: Go 1.23 Released

#79

Post by Zuiii »

wsve wrote: post #77
kingsleyopara wrote: post #54

Earlier quoted context omitted.

Privacy concerns aside, I personally don't appreciate binaries making network requests unless it's strictly required for them to function.

Where is that line for you? Is occasionally checking for security updates strictly necessary? Is reporting a crash to the devs so they can fix it necessary? What about sending system & usage telemetry so they can prevent future bugs?

For me, it's like GP said: Absolutely no unauthorized network traffic unless strictly required for the purpose of the software (e.g. curl). No security updates, crash reporting, telemetry unless you prompt the user and show the user exactly what will be sent (similar to how syncthing does it).

Anything less is voyeurism.*

* extreme language I know, but it's precisely how I feel about these acts.

Re: Go 1.23 Released

#80

Post by synicalx »

etse wrote: post #74
traceroute66 wrote: post #41

Earlier quoted context omitted.

> Great job Go. Hat tip and respect for this Whoah. Easy there cowboy. It was not opt-in when originally announced. After an extended, shall we say, "lively" discussion on Github[1], they did the right thing and made it opt-in. (N.B. The discussion was heavily moderated and redacted, it was even more "lively" at the time.) [1] https://github.com/golang/go/discussions/58409

Are you opposed to the process by which discussion can initiate a transition from negative state to positive state? Seems healthy to me.

To me, even proposing the (extremely obviously) negative state in the first place is a sign of bad faith on the part of the proposer.

If they proposed kicking puppies twice a day, and after some discussion decided to not do that would we all be applauding their decision?

Post reply on HN