Go 1.26 is released
92 points by achill
92 points by achill
We run a large (100k lines) Go codebase. We should be shipping a new release with 1.26/Green Tea sometime in the next week or two, assuming testing goes well. I'm curious to see how much of a free performance boost we get.
I got a slight performance decrease when using GOEXPERIMENT=greenteagc with Go 1.25 for the Algernon web server, but it sounds like a very promising GC algorithm, and there are many other performance improvements for Go 1.26.
The implementation changed a bit in 1.26 in response to data we gathered from regressions, and it's not just the AVX-512 stuff. I encourage you to measure it again and file a bug if you still see a regression.
For some inputs/jobs in our code base we can fall into a situation where about 25% of our time is dedicated to doing GC (we’re slowing fixing this), so I’d expect to see something magical happen.
I'm thinking of switching to Go from Rust. Life doesn't have to be that complicated.
I write both rust and go and still prefer go. For the applications I need to write, the complexity of rust is not justified.
Rust realistically has only given me aggravation on every level. It's cool and correct and whatever, but still not really worth it for somebody programming on the side.
Looks like I'm not alone in misreading "to Go from Rust" as "from Go to Rust". :)
Go is definitely a lot easier unless you're doing either super high-performance stuff or super abstract stuff.
Interesting, I find this sentiment surprising! My experience as both a Go developer and maintainer is that Go releases require essentially no attention at all: update the version in the go.mod and everything keeps working the same, sometimes faster.
Could you share a couple examples of pain points in upgrading to Go 1.26?
From reading the OP they seem to be saying that they're switching from Rust -> Go, not the opposite. And I imagine "life doesn't have to be that complicated" related to the fact Go is a simpler language in general.
I don't remember hearing about this planned change, but I like it (and its justification): https://go.dev/doc/go1.26#go-command
go mod initnow defaults to a lower go version in new go.mod files. Running go mod init using a toolchain of version 1.N.X will create a go.mod file specifying the Go version go 1.(N-1).0. Pre-release versions of 1.N will create go.mod files specifying go 1.(N-2).0. For example, the Go 1.26 release candidates will create go.mod files with go 1.24.0, and Go 1.26 and its minor releases will create go.mod files with go 1.25.0. This is intended to encourage the creation of modules that are compatible with currently supported versions of Go. For additional control over the go version in new modules, go mod initcan be followed up with go get go@version.
That is actually a good change. Every time I start a new Go project I always need to tweak Go versions, especially because generally I package them in a flake.nix file too and nixpkgs rarely has the latest Go version available by default. So unless I am using some new feature, I generally tweak the go.mod file to use the previous stable version anyway.
I also like that they will now use the .0 release by default instead of the whatever is the current patch version that I am using.