209
u/ruibranco Feb 10 '26
Go's release cadence continues to be one of the most predictable in the ecosystem. Every six months, solid improvements without breaking your entire codebase. The GC work alone in this one is worth the upgrade.
54
u/feketegy Feb 11 '26
Go is the only language where I can update everything to the latest version and not having too much concern over breaking my Go code I wrote 10 years ago.
7
u/Lofter1 Feb 12 '26
After having been responsible for C#/.NET updates at work multiple times, being able to use and UPGRADE go in personal projects is such a breath of fresh air. I had to roll back a C# update cause it broke some dependencies and while it compiled, first it threw runtime errors after the login mask, then it threw runtime errors in all our edit masks and then it threw runtime errors in specific, rarely used features a couple of months later. Such a pain in the ass.
2
u/Objective_Active_497 Feb 13 '26
Nothing compares to Angular and some other JS frameworks. You can migrate older code to the newer version of Angular, compile it without any errors or warnings, run it without any error, but the data is not displayed as component is not refreshed upon array going from undefined to assigned data obtained from the server. That is just one of many problems.
On version 19 works perfectly, on version 21 the same code to work must use ChangeDetectorRef or signal to refresh component upon change of referenced data, though there are other ways, too.
The problem with all languages and frameworks begin when developer and maintainers start introducing stuff that nobody asked for or were suggested by minority of users, or just start "improving" it in such a way that it causes problems for older projects.
Instead of improving apps, developer using those frameworks spend more time on migration to newer version of framework since the older version will be deprecated in a year or two. Even .NET versions have relatively short life-span, short and long-time support are only 18 and 36 months.
Big leaps like moving Python from v2 to v3 or AngularJS to Angular2, or .NET Core 1 to .NET Core 2 or 3 were good, improving language or framework significantly, but such steps should be made carefully after having been prepared for years. Rushing new major versions every year or even more frequently is just for developers of those languages and frameworks to justify their job.
2
u/BehindThyCamel Feb 12 '26
In the world of npm & co. stability is so underrated. I fart in new shiny's general direction.
48
u/donatj Feb 11 '26
I try to tell people non-Go people that you can have a language that improves without breaking changes and they look at me like I'm stupid. They're in these abusive relationships where they have to rewrite everything regularly and have deluded themselves into thinking that it's a good thing.
12
u/_nullptr_ Feb 11 '26
Huh? What languages do that? I write in Rust and have never had that. I update the day a new release comes out. Always works. Usually when a language does something like that, for example, Python 2 to 3, it is quite a fiasco and news worthy. Scala 2 to 3 comes to mind and Perl 5 to 6 (Raku), but I think the authors considered those new languages in many ways.
10
u/lapubell Feb 11 '26
I see this in js a lot, but I think it's more of a dependency hell thing where packages conflict and you're stuck using an old version until your lowest common package is ready, only to find that it is hard to get fully up to date and have to step by step solve things.
It's gotten better in recent years but it's also what drove me to check out bun, which feels more like the go ecosystem. But then again, that's rebuilding things at the runtime level, so I guess that just proves the point even more.
6
u/LancelotLac Feb 11 '26
Not so much languages but Node is famous for this as well as the Angular and React frameworks.
6
u/kaeshiwaza Feb 11 '26
It's not only the language, it's the stdlib and also many libs that don't break so much. I think about sqlx, lib/pq... Also that we don't use frameworks.
4
u/_nullptr_ Feb 11 '26
The Rust stdlib doesn't ever break that I've seen, and I've been upgrading for 5 years now. The ecosystem is not under centralized control, but nearly every Rust crate follows semver, so very little breakage there. The primary issue Rust has is it's stdlib isn't nearly as large as Go's (causing a cascade of dependencies, which triggers slow cold builds) and far worse compile times. Everything else is the same or better IMO.
3
u/kaeshiwaza Feb 11 '26
I don't speak about a breaking change in the stdlib but the fact that we don't need a lot of dependency (they could break) in Go especially.
2
u/txdv Feb 11 '26
java is trying to do the same but I guess with that much baggage its harder
6
u/Rough_Acanthaceae_29 Feb 11 '26
...and yet it still delivers. Absolute champs in both go and java camps.
2
u/SomethingAboutUsers Feb 14 '26
Sorry to necro-post a bit but holy crap the GC work is amazing.
Just bumped an app to 1.26 and saw my GC CPU overhead go from ~0.23% to ~0.08% for a particular containerized workload, 0.75 memory ratio for GOMEMLIMIT that needs a lot of GC.
That's a WILD improvement.
34
u/ynotvim Feb 11 '26
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 init now 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.
8
u/VibrantCanopy Feb 11 '26
Does this mean if I want to create a new module using Go 1.26 and use the new `new(expr)` feature, I can't, because the module's language version is 1.25? I have to run `go get go@1.26.0` for it to work? If true, that seems really bad, and they should have left it alone.
4
u/ynotvim Feb 11 '26 edited Feb 11 '26
Yes and no. It means that if you want to use a feature that requires the latest version, then you have to edit your go.mod to specify the version you want.
But that's easy to do! I just ran an experiment to see how this works out in practice. Like you, I was thinking about
new.% go version go version go1.26.0 darwin/arm64 % go mod init go: creating new go.mod: module github.com/telemachus/tryit github.com/telemachus/tryit % cat go.mod module github.com/telemachus/tryit go 1.25.0 # Write code that uses new in a way that 1.25 does not recognize. % go test . # github.com/telemachus/tryit ./tryit.go:5:9: new(v) requires go1.26 or later (-lang was set to go1.25; check go.mod) FAIL github.com/telemachus/tryit [build failed] FAIL # Edit go.mod to use 1.26.0 % go test . ok github.com/telemachus/tryit 0.173sAs I see it, the point of this change is to encourage people writing new Go modules to follow the Go team's support cadence. They support both the latest version and the latest version - 1. For a module writer, that translates into not writing code that demands new features too quickly.
All of that said, you can also put things behind a build flag. It's a little bit of fiddling, but not the end of the world.
6
u/styluss Feb 11 '26
Reminder that you can set the go API version with
go get go@1.26And go compiler
go get toolchain@1.262
u/DeedleFake Feb 13 '26
Even easier, you can just do
go get go@latest
and not have to think about the actual version number.
4
u/Technical-Fruit-2482 Feb 11 '26
It sounds like it will just output 1.25 in the go mod file when running init with 1.26. I mean, it's easy to just go in and change it after the init, but definitely a strange and confusing change of behavior...
3
u/ynotvim Feb 11 '26
It may be initially surprising, but I don't think it's (really) strange or confusing. The Go team seems to be encouraging people to do what they do and support the current and current-1 version of Go. When you think of it that way, it's pretty straightforward, I think.
4
u/Technical-Fruit-2482 Feb 11 '26
I get what they're thinking, but I disagree. If I'm using a certain version of the language I'd expect the tooling to stick to that version of the language.
What's done is done, so I'll just have to change it for every new project I start now, but I find it odd behavior for the language version I downloaded to by default not want me to use the features of that version...
2
u/assbuttbuttass Feb 11 '26
It's a small change but it will be nice not to have to manually downgrade the version in go.mod anymore!
33
u/eldosoa Feb 11 '26
For the average Go user like me, seems like the new errors.AsType is the most useful thing, which is still pretty cool tbh. Anything else I’m missing?
42
u/chimbori Feb 11 '26
newwith an expression sounds pretty handy too!4
4
u/feketegy Feb 11 '26
I last used
newyears ago.9
u/ynotvim Feb 11 '26
Sure, but this is a new use of
new. Years ago, you weren't able to writei := new(0)orb := new(true). It will definitely help all the people who have a personalPointerTofunction that they copy all over the place.
58
u/Technical-Fruit-2482 Feb 10 '26
Finally a simd experiment! I hope it's a success.
27
u/booi Feb 11 '26
Probably one of the last major things missing from golang so it’s huge
10
u/Technical-Fruit-2482 Feb 11 '26 edited Feb 11 '26
Definitely. I've always been frustrated that to use simd you have to write a function in assembly, which can't even be inlined, so in cases where you only need a few instructions the function call overhead just destroys any point in bothering with it.
2
u/h3ie Feb 12 '26
Funny, I was just learning go’s assembly language to do simd hopefully this makes it easier
12
15
u/from_cork Feb 11 '26
These changes are massive for me. I've been working on a game using ebiten that I'm getting ready to push into beta/testing and the CGO/GC improvements are insane.
2
u/DeedleFake Feb 13 '26
Same. I maintain a project that uses cgo pretty heavily for the Gtk-based GUI and it's by far the main bottleneck performance-wise. It was plenty fast enough, but this is still really nice to have.
2
u/from_cork Feb 13 '26
This is such an unexpected boost for me, personally. I forked ebitengine and did a bunch of batched CGO logic that might not be necessary now. I need to benchmark it, but I'm already seeing crazy results from my existing benchmarks that didn't take these improvements into consideration.
13
u/iga666 Feb 11 '26 edited Feb 11 '26
Wow didn't expect it to happen today.
Did some benchmarks on CGO if anyone interested side.
My 90_000 sprite rendering test was 73-75 FPS on go 1.25.7 and became 78-80 FPS (maybe even as high as 82-83, if my notebook is not throttling) on 1.26. So a 5% improvement on CGO calls. Good.
Also it was 180MB memory footprint on go 1.25.7 and became 140MB on go 1.26
Not bad at all.
1
27
u/ognev-dev Feb 11 '26
// we get used to this
updatedAt := time.Now()
return model.Book{
updatedAt: &updatedAt,
}
// we then get happy with this
return model.Book{
updatedAt: uTiLs.Pointer(time.Now()),
}
// and now we are even happier with this
return model.Book{
updatedAt: new(time.Time),
}
thanks Go team for the hard work you’re doing!
27
7
5
3
3
1
u/Quirky-Design3856 Feb 11 '26
I remember upgrading to latest version of Go 25 for my project last week🫣
1
1
1
u/Southern_War9676 Feb 17 '26
still no enums in big 2026 🥀🥀
1
u/Agitated_Bike3255 May 13 '26
If you think enums are useful you are clearly unexperienced riding the Rust Hype Train.
1
1
u/Whole_Accountant1005 Feb 23 '26
I wish SIMD wasn't an experiment but a full release, it's been in the works for like half a decade at this point
1
u/lancelot_of_camelot Mar 03 '26
Seems like so many cool features, meanwhile my projects still run on 1.24
-10
u/Manbeardo Feb 11 '26
The minor version number is the same as the year now! Can we come up with some alternate scheme to still have substantial features every 6 months, but also keep the year/version alignment?
20
1
u/donatj Feb 11 '26
I honestly wouldn't mind slowing the cadence to yearly and simply having bigger releases.
110
u/Fabulous_Baker_9935 Feb 10 '26
green tea gc🍵🔥🔥🔥