Live data from Hacker News

Go 1.23 Released

go.dev

81–90 of 106 posts

Re: Go 1.23 Released

#81
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

I'd bet you dollars to donuts that the Go team originally asked for opt-in and got overruled by suits.

Re: Go 1.23 Released

#82
I'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).

Re: Go 1.23 Released

#83

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]

I'll agree with you that it is a very "mild" case of magic, or maybe this doesn't qualify as magic at all because Go doc is pretty good. But having to build the docs and then learning what m.Range does adds extra inconvenience to what until now was just an eyeball scan operation of the "for" line.

Re: Go 1.23 Released

#84

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

Not a fan either, this release feels like it’s shoehorning FP into Go.

Re: Go 1.23 Released

#85
post #77

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?

> Where is that line for you?

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

#86
post #75

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

Probably a higher chance of that being noticed though. ;)

Re: Go 1.23 Released

#87

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

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

I don't believe the Go team deciding not to break GDPR law after massive backlash is anything that should be applauded.

Re: Go 1.23 Released

#88
post #77

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?

Do you know the definition of the word strictly? No, security and upstream convenience are not even remotely necessary for a tool to work

Re: Go 1.23 Released

#89
post #20

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

Maybe if all you want to do is read code, but if you want to write it you need to know stuff like the fact there's no inheritance or generics, that public methods are define with capital letters and to parse json you need to use magic annotations.

Re: Go 1.23 Released

#90

I'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).

You could do:

    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)
    }
Post reply on HN