We go to great lengths to uphold the Go 1 Compatibility Promise, ensuring Go programs keep compiling and running correctly with the latest release. Backwards incompatible changes are simply not contemplated.
(We are in the early days of a “Go 2” effort which might introduce backwards incompatible changes with module-level opt-in, which should allow forward progress without breaking existing code or fracturing the ecosystem.)
This has a lot of costs, mostly borne by the team (as opposed to community developers), but a critical dividend is the fact that we can mostly assume people are using recent versions.
I recommend assuming the Go packaged with your (non-rolling) distribution is part of the machinery that builds other packages, not something for you to consume, and to install an up to date Go if you directly use the go tool.
Finally, with my security coordinator hat on, we currently only accept vulnerability reports and publish security patches for the latest two release, so while the security teams of distributions might be doing backports it’s unclear if anyone is looking for or acknowledging vulnerabilities in unsupported releases.
P.S. it also occurs to me now that if distributions modify the Go compiler or standard library (for example to backport fixes) the builds they generate won’t be reproducible by others.
Thank you for your work! There are way too many components that make things easier for themselves and create lots of work for their users. I find that a terrible trade-off and I really appreciate how Go does it better.
A big reason that I can easily use the latest Go is that I only have to update the SDK. I don’t have to also roll out a new runtime to all my deployment targets.
Heh. Yes, pretty much. Typically there are strong reasons not to upgrade (specifically, a lack of care taken with backwards compatibility) - which IME does not apply particularly to go.
We’ve bricked ourselves into a corner with this where I work. A few years ago we started developing a CLI for some internal web services, and the tool is used across a large estate of platforms now. Unfortunately, as with many financial services institutions, legacy tech is prevalent, and I do mean legacy. We still have some RHEL-4 boxes kicking around. When we started building this tool, we hadn’t actually looked at the kernel versions Go was supported on - and we didn’t notice a problem. All the builds of the tool ran everywhere.
Then we updated our go tool chain above 1.10, and suddenly we were getting panics from the new binary on these old platforms. Turns out the kernel they run is not support by Go - but we had had no idea up to that point.
Now that means we’re stuck building our tool with 1.10, and cannot use any new Go language features as a result. Sad times.
I feel both sides of this problem. One of the products I deal with at work is still using Java 6 (due to a tool that calls the Java directly). Even in Java’s slow moving ecosystem that’s old. This is logjamming a whole bunch of other toolchain/infrastructrue/framework updates as well.
With the product that’s in Go, they had been updating the OS underneath and the upgrades (with several years between touching the product) was pretty pleasant; modules were welcome despite being some initial work.
Strongly endorsed.
We go to great lengths to uphold the Go 1 Compatibility Promise, ensuring Go programs keep compiling and running correctly with the latest release. Backwards incompatible changes are simply not contemplated.
(We are in the early days of a “Go 2” effort which might introduce backwards incompatible changes with module-level opt-in, which should allow forward progress without breaking existing code or fracturing the ecosystem.)
This has a lot of costs, mostly borne by the team (as opposed to community developers), but a critical dividend is the fact that we can mostly assume people are using recent versions.
I recommend assuming the Go packaged with your (non-rolling) distribution is part of the machinery that builds other packages, not something for you to consume, and to install an up to date Go if you directly use the go tool.
Finally, with my security coordinator hat on, we currently only accept vulnerability reports and publish security patches for the latest two release, so while the security teams of distributions might be doing backports it’s unclear if anyone is looking for or acknowledging vulnerabilities in unsupported releases.
P.S. it also occurs to me now that if distributions modify the Go compiler or standard library (for example to backport fixes) the builds they generate won’t be reproducible by others.
Thank you for your work! There are way too many components that make things easier for themselves and create lots of work for their users. I find that a terrible trade-off and I really appreciate how Go does it better.
A big reason that I can easily use the latest Go is that I only have to update the SDK. I don’t have to also roll out a new runtime to all my deployment targets.
You’d think that should apply to all programming language implementations? 🤔
Heh. Yes, pretty much. Typically there are strong reasons not to upgrade (specifically, a lack of care taken with backwards compatibility) - which IME does not apply particularly to go.
Yeah, but the way Go does should really be how everyone does it.
We’ve bricked ourselves into a corner with this where I work. A few years ago we started developing a CLI for some internal web services, and the tool is used across a large estate of platforms now. Unfortunately, as with many financial services institutions, legacy tech is prevalent, and I do mean legacy. We still have some RHEL-4 boxes kicking around. When we started building this tool, we hadn’t actually looked at the kernel versions Go was supported on - and we didn’t notice a problem. All the builds of the tool ran everywhere.
Then we updated our go tool chain above 1.10, and suddenly we were getting panics from the new binary on these old platforms. Turns out the kernel they run is not support by Go - but we had had no idea up to that point.
Now that means we’re stuck building our tool with 1.10, and cannot use any new Go language features as a result. Sad times.
I feel both sides of this problem. One of the products I deal with at work is still using Java 6 (due to a tool that calls the Java directly). Even in Java’s slow moving ecosystem that’s old. This is logjamming a whole bunch of other toolchain/infrastructrue/framework updates as well.
With the product that’s in Go, they had been updating the OS underneath and the upgrades (with several years between touching the product) was pretty pleasant; modules were welcome despite being some initial work.