Opt-in telemetry. A very rare sight these days. Glad to see.<p>Not even Mozilla does that with Firefox [1].<p>> 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.<p>> Go telemetry is an opt-in system, controlled by the go telemetry command. By default, the toolchain programs collect statistics in counter files that can be inspected locally but are otherwise unused (go telemetry local).<p>> To help us keep Go working well and understand Go usage, please consider opting in to Go telemetry by running go telemetry on. In that mode, anonymous counter reports are uploaded to telemetry.go.dev weekly, where they are aggregated into graphs and also made available for download by any Go contributors or users wanting to analyze the data. See “Go Telemetry” for more details about the Go Telemetry system.<p>[1] "Firefox collects telemetry data by default. We collect this data to help improve the performance and stability of Firefox. Telemetry data is made up of two data sets: interaction data and technical data." - <a href="https://support.mozilla.org/en-US/kb/telemetry-clientid" rel="nofollow">https://support.mozilla.org/en-US/kb/telemetry-clientid</a>
If you find the official release notes a bit dry (they really are), I've prepared an interactive version with lots of examples:<p>- Iterators (range / types / pull / slices / maps).<p>- Timer changes (garbage collection and reset/stop behavior).<p>- Canonical values with the `unique` package.<p>- HTTP cookie handling.<p>- Copying directories.<p>- Slices and atomics changes.<p><a href="https://antonz.org/go-1-23" rel="nofollow">https://antonz.org/go-1-23</a>
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`<p>> 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:build constraints in the file.)
>
> For example, it will report a diagnostic for a reference to the reflect.TypeFor function (introduced in go1.22) from a file in a module whose go.mod file specifies go 1.21.
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.
From the release notes [1], which I think this post should actually point to:<p>> For backward compatibility, existing usages of //go:linkname found in a large open-source code corpus remain supported. Any new references to standard library internal symbols will be disallowed.<p>How does this work? Does the compiler have a whitelist of allowed uses?<p>[1]: <a href="https://go.dev/doc/go1.23" rel="nofollow">https://go.dev/doc/go1.23</a>
direct link to the release notes: <a href="https://go.dev/doc/go1.23" rel="nofollow">https://go.dev/doc/go1.23</a>
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).