This guy should work on the official release notes! I have to admit, even knowing what was coming in Go 1.23, I found the release notes pretty hard to read.
Thanks for the link. I finally understand how the iterator works thanks to this article. I think the fact that the author explain the for range changes separately from the iterator types helps (most other articles explained them together and make it difficult for me to understand, especially because of the confusing signature of the iterators).
I recall the Go authors saying opt-in telemetries will cause skewed results, since people who opt into telemetries represent the whole output, and cannot be used to make language changes… Guess we’ll see how it goes after this telemetry runs for a while.
I don’t write much go these days, but I’ll likely opt in once I’ve seen what’s submitted. Broadly, I think all of the following are true:
software is made better through feedback
representative feedback is really hard to collect for a language compiler
So anonymous information about which flags/commands/configurations are used strikes me as both pretty harmless and extremely beneficial to the project.
You can see what they collect here, which is neat. There’s also a local mode that will collect the data but not ship it up (I’m assuming so people can audit what’s sent to help decide if they want to fully enable it).
For my local dev environment I will leave it set to “local” (the default). It will be interesting to see some of the stats like the compiler cache hit ratios. I will consider doing manual uploads using “gotelemetry upload”. I think that’s a good compromise.
In practical terms, this forces the Go compiler to arrange a struct in memory like C would in the host system the code will run on. This in turn lets you pass a struct to C code as if it was a native C struct. This is useful to call libraries written in C (typically via cgo) from Go code.
My understanding is that Go already does this by default, but they’d like to stop doing that and only do it when actually required (ie. for structs marked with this HostLayout feature). This enables optimizations.
The linker now disallows using a //go:linkname directive to refer to internal symbols in the standard library (including the runtime) that are not marked with //go:linkname on their definitions. Similarly, the linker disallows references to such symbols from assembly code. 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.
This is an excellent example of “when you make something simple, you move complexity elsewhere”.
If misuse of this feature to link against private APIs is so pervasive that they felt it necessary to make a list of exceptions in the compiler, this is a very clear indication that there is something missing in the standard library, or the compiler, or both.
I certainly hope that the long-term plan here is more than just pulling the rug out from everyone.
Anton Zhiyanov has great interactive release notes if you want to play with any of the new features: https://antonz.org/go-1-23/
This guy should work on the official release notes! I have to admit, even knowing what was coming in Go 1.23, I found the release notes pretty hard to read.
Discussion on Anton’s release notes: https://lobste.rs/s/gow5jc/go_1_23_interactive_release_notes#c_no5l2g
Thanks for the link. I finally understand how the iterator works thanks to this article. I think the fact that the author explain the
for rangechanges separately from the iterator types helps (most other articles explained them together and make it difficult for me to understand, especially because of the confusing signature of the iterators).I recall the Go authors saying opt-in telemetries will cause skewed results, since people who opt into telemetries represent the whole output, and cannot be used to make language changes… Guess we’ll see how it goes after this telemetry runs for a while.
Would you opt in and why/why not?
I like the following approach: opt in when opt-in, opt out when opt-out.
I don’t write much go these days, but I’ll likely opt in once I’ve seen what’s submitted. Broadly, I think all of the following are true:
So anonymous information about which flags/commands/configurations are used strikes me as both pretty harmless and extremely beneficial to the project.
You can see what they collect here, which is neat. There’s also a local mode that will collect the data but not ship it up (I’m assuming so people can audit what’s sent to help decide if they want to fully enable it).
At Work this would be killed by legal I assume. For private stuff maybe
For my local dev environment I will leave it set to “local” (the default). It will be interesting to see some of the stats like the compiler cache hit ratios. I will consider doing manual uploads using “gotelemetry upload”. I think that’s a good compromise.
At work none of this is going to get past the perimeter and that would be true for nearly everywhere I’ve worked, so the results are already skewed.
I don’t understand structs.HostLayout. Could somebody give me an example of how its used?
In practical terms, this forces the Go compiler to arrange a struct in memory like C would in the host system the code will run on. This in turn lets you pass a struct to C code as if it was a native C struct. This is useful to call libraries written in C (typically via cgo) from Go code.
My understanding is that Go already does this by default, but they’d like to stop doing that and only do it when actually required (ie. for structs marked with this
HostLayoutfeature). This enables optimizations.More details and nuance in the proposal.
Without having benchmarked anything yet, executables compiled with this version feels a lot faster than before.
This is an excellent example of “when you make something simple, you move complexity elsewhere”.
If misuse of this feature to link against private APIs is so pervasive that they felt it necessary to make a list of exceptions in the compiler, this is a very clear indication that there is something missing in the standard library, or the compiler, or both.
I certainly hope that the long-term plan here is more than just pulling the rug out from everyone.
For anyone interested, I think this is the issue that talk about the
//go:linknamechanges: https://github.com/golang/go/issues/67401.The main reason seems to be https://github.com/goccy/go-json, used by Kubernetes, but it probably affect some other packages too.