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

91–100 of 106 posts

Re: Go 1.23 Released

#91

Post by tharax »

ianlancetaylor wrote: post #55
rollcat wrote: post #45

Earlier quoted context omitted.

Google can already see every installation of every Go program/package in existence, unless you set GOPROXY=direct (or a custom proxy). The default is to use https://proxy.golang.org , which is operated by Google.

The default proxy has a privacy policy: https://sum.golang.org/privacy .

But better than this is would be if my go tooling didn't default to trying to pull codebases through a proxy

Forgive me for being cynical, but I don't like that out of the box the toolchain tries to pull all the code at `example.com/business/logic` through google servers.

Re: Go 1.23 Released

#92

Post by Expurple »

progbits wrote: post #65
epage wrote: post #11

As someone who was advocating for a similar warning in Rust (finally added to clippy in 1.78), I'm glad to see this improvement in `go vet` > The go vet subcommand now includes the stdversion analyzer, which flags references to symbols that are too new for the version of Go in effect in the referring file. (The effective version is determined by the go directive in the file’s enclosing go.mod file, and by any //go:bu…

Don't most Rust crates solve this by running MSRV builds/tests? Or is the goal to catch it eg. in precommit hook?

Clippy is both faster in the CI and can be integrated into an IDE feedback

Re: Go 1.23 Released

#93

Post by adonovan »

euroderf wrote: post #81
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

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

You have it backwards. The suits are way more comfortable with privacy violation than the Go team.

Re: Go 1.23 Released

#94

Post by icholy »

candiddevmike wrote: post #15
glzone1 wrote: post #13

Earlier quoted context omitted.

Are you talking about for key, val := range m.Range I like that a fair bit more than m.Range(func(key, val any) bool {

But now I have to understand what m.Range does, and I can't assume it's a slice or a map etc. Prior to this change, you could almost always correctly assume what a for loop is doing as it was very primitive. It's changes like this that will make Go less productive for users over time, IMO. Java-fication.

You seem to have forgotten that it's possible to range over channels.

Re: Go 1.23 Released

#95

Post by saturn_vk »

candiddevmike wrote: post #15
glzone1 wrote: post #13

Earlier quoted context omitted.

Are you talking about for key, val := range m.Range I like that a fair bit more than m.Range(func(key, val any) bool {

But now I have to understand what m.Range does, and I can't assume it's a slice or a map etc. Prior to this change, you could almost always correctly assume what a for loop is doing as it was very primitive. It's changes like this that will make Go less productive for users over time, IMO. Java-fication.

Even if you don't have any help from an LSP, I don't really see how this change adds any meaningful complexity.

With `for x, y := range m.Range`, you know you are iterating over something, and you are getting an `x` and a `y`. For the purposes of understanding the range block and what it does, it doesn't really matter what `m.Range` is, only that it allows iteration. Just like you don't care in <=1.22 land whether `m.Range` is a slice, map, or channel, because for the purposes of understanding the code, that doesn't matter.

Re: Go 1.23 Released

#96

Post by kjs3 »

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.

There's the "If you have nothing to hide..." guy.

Re: Go 1.23 Released

#97

Post by euroderf »

adonovan wrote: post #93
euroderf wrote: post #81

Earlier quoted context omitted.

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

You have it backwards. The suits are way more comfortable with privacy violation than the Go team.

You have me backwards cos I had it forwards. I was unclear perhaps.

I meant (a) "someone" (suits?) said let's install telemetry, (b) the Go team said well hey come on let's make it opt-in rather than defaulting to "on", (c) suits said no we just sneak in the default "on" (cos google ebil).

Re: Go 1.23 Released

#98

Post by euroderf »

EdiX wrote: post #90
euroderf wrote: post #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).

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) }

OK, this works cos package ast already has `func Inspect`.

So how about a more general case ? A case where we do not have a `func Inspect` already in the stdlib ?

Maybe just replace it with (for example) `filepath.WalkDir` ?

Re: Go 1.23 Released

#99

Post by adonovan »

euroderf wrote: post #97
adonovan wrote: post #93

Earlier quoted context omitted.

You have it backwards. The suits are way more comfortable with privacy violation than the Go team.

You have me backwards cos I had it forwards. I was unclear perhaps. I meant (a) "someone" (suits?) said let's install telemetry, (b) the Go team said well hey come on let's make it opt-in rather than defaulting to "on", (c) suits said no we just sneak in the default "on" (cos google ebil).

Well I can assure you that is not what happened. Our team tried to come up with a telemetry design that set a higher bar for privacy preservation than the norms of the industry (including Google), something so safe that it would be acceptable to enable by default. Of course, the community rejected it and that plan died. But the "suits" at Google afford our team enough autonomy to act in the best interests of the Go community.

Google is not quite the monolithic James Bond villainy of your caricature.

Re: Go 1.23 Released

#100

Post by frosting1337 »

_xiaz wrote: post #87
frosting1337 wrote: post #73

Earlier quoted context omitted.

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.

I'm not really understanding the logic here, but you do you bud.
Post reply on HN