Go 1.26 Release Notes(go.dev)
go.dev
Go 1.26 Release Notes
https://go.dev/doc/go1.26
6 comments
We changed the way we track Go threads in syscalls/cgo calls, which allowed us to remove one atomic store and one atomic compare-and-swap from the cgo call path. https://go.dev/cl/646198 and https://go.dev/cl/708596 are the relevant changes.
(It's basically an easter egg, but if you look at the source of the release notes, you will see that most entries in the release notes have an HTML comment referencing the Go CL or issue that the entry refers to.)
(It's basically an easter egg, but if you look at the source of the release notes, you will see that most entries in the release notes have an HTML comment referencing the Go CL or issue that the entry refers to.)
My favorite from this release.
> The built-in new function, which creates a new variable, now allows its operand to be an expression, specifying the initial value of the variable.
So no need for separate helpers anymore to instantiate a pointer to a literal.
> The built-in new function, which creates a new variable, now allows its operand to be an expression, specifying the initial value of the variable.
So no need for separate helpers anymore to instantiate a pointer to a literal.
Now if only the Go gods would grant us in line ternaries to avoid all of the overly verbose nil checks, I'd be more likely to use pointer values in structs. Right now they're big foot guns that the compiler won't catch (and AFAIK no linter will check if you did a nil check before accessing).
I have a tech debt TODO on my backlog to rationalize null usage (waiting on encoding/jsonv2) where I'll go through structs and better determine which properties should be null (or even empty) both from a JSON and DB perspective, especially with custom types in the mix. Hopefully reducing the amount of possible values the TS frontend needs to handle...
I have a tech debt TODO on my backlog to rationalize null usage (waiting on encoding/jsonv2) where I'll go through structs and better determine which properties should be null (or even empty) both from a JSON and DB perspective, especially with custom types in the mix. Hopefully reducing the amount of possible values the TS frontend needs to handle...
> the compiler can now allocate the backing store for slices on the stack in more situations
Any details on when this happens?
Any details on when this happens?
see: https://go-review.googlesource.com/c/go/+/707755 and https://go-review.googlesource.com/c/go/+/664299
Looks for slices with lengths <= 32.
Looks for slices with lengths <= 32.
This is great, but tell me more? What happened?