Just to throw in my 2c, I've had significant breakages with most Go upgrades. I've had far fewer issues with rust upgrades, and gcc upgrades. C and Rust compile

Just to throw in my 2c, I've had significant breakages with most Go upgrades. I've had far fewer issues with rust upgrades, and gcc upgrades. C and Rust compiler updates feel actually backwards compatible to me. I posted a list of a few breakages I've run into before, though of course I've run into more since, and far more I didn't mention there: https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 I think the main reason I've had more issues with Go upgrades than with Rust upgrades or C upgrades is because for rust/gcc, I'm upgrading the compiler and getting language features, but most of the complex libraries don't change, and I can upgrade them separately from the compiler (i.e. hyper for http in rust, or libcurl in C). For go, whenever I upgrade the compiler, I get a mix of language features (generics, embed, other toolchain features), but also a set of library updates (tls and security libraries yet again dropping support for something I use, http client or server changes, etc). I think go would have been much better served by making 'http', 'tls', 'crypto', and other large chunks of the standard library their own separate libraries. Even if you kept the exact same go1 promise for those (which is to say "we sometimes break http and tls, but we tell you it's backwards compatible"), it would be far better because I could then actually fearlessly upgrade the go compiler version, and then later upgrade those libraries at my own pace. Or, when the tls upgrade breaks my code for the nth time, I could roll it back without also having to roll back the entire compiler version and revert any code changes which used new compiler features. It also really makes no sense for libraries like 'http' and 'archive/*' to be part of the standard library. Presumably they're just there because the Go team wanted to release 1.0 before figuring out a good dependency system (though golang.org/x/ was a really quick follow-on, and that would have been enough for these), but that has led to the "go 1 compatibility promise" really meaning "enough go upgrades break my code that I'm scared to update, but not because the compiler has a breaking change, but because some part of the stdlib that doesn't even need to be bundled with the compiler breaks me".