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
Go 1.23 Released
81–90 of 106 posts
Re: Go 1.23 Released
#82Re: Go 1.23 Released
#83Earlier 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]
Re: Go 1.23 Released
#84I don't like the "range-over-func" addition. I feel like it is adding complexity and syntactic sugar to the language that has thus far been mostly avoided.
Re: Go 1.23 Released
#85Earlier 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?
None of the above is acceptable. Crash reporting can generate its output locally for people to manually send, if they choose to do so.
Re: Go 1.23 Released
#86Earlier quoted context omitted.
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
#87Earlier 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
But it is now, and that's good and should be applauded.
Re: Go 1.23 Released
#88Earlier 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?
Re: Go 1.23 Released
#89Any good resources on learning go? Has anyone had any luck with the YT videos or courses way?
I hope I don't sounds rude saying this but Go code is generally self evident. I personally got my Go knowledge from reading Go code on GitHub or the like. There's a certain beauty to Go code in that you can grasp what code does pretty easily, which definitely helps with learning.
Re: Go 1.23 Released
#90I'd like to see a best-practices range-compatible depth-first preorder push iterator for a tree. Any tree implementation would do for purposes of exposition; for example package ast, where node order is important, unlike package filepath. FWIW there is current discussion in issue 64341 (and also 61405).
func inspect(n ast.Node) func(func(ast.Node) bool) {
return func(f func(ast.Node) bool) {
ast.Inspect(n, f)
}
}
used: for n := range inspect(f) {
fmt.Printf("%T\n", n)
}