Go hasn't had a history yet of breaking compatibility with earlier releases. Wait until Go 2 comes out, then we'll see how much Google wants to maintain long-term support. Two hints: it'll be at least as long as necessary for Google to port all of its Go 1 code to Go 2, and it won't be much longer than support for Inbox or Google Reader. And a further hint, Google will figure out how to port all of its Go 1 code to Go 2 much faster than you think, and your company will not be able to port its million-line Go codebase nearly as quickly.
One of the stated goals of Go2 is forward and backward compatibility. We have to see how well this pans out when Go2 is released.
> Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part.
It's an admirable goal, and we'll see whether it works out in practice. Remember, this entire thread is about JDK updates. Java also explicitly has forward and backward compatibility as a design goal, but then sun.misc.Unsafe turned out to be a bigger headache than most people thought, and upgrading to Java 11 will require many companies to update core dependencies, and unfortunately a lot of companies would rather pay for Java 8 support than put in the maintenance effort.
Even if there's 99% compatibility, if upgrading requires anything more than updating the compiler, even if it's just adding a runtime flag and the upgrade effort should be minimal, you're going to see significant resistance from companies with large codebases.
Google treat consumer products differently to commercial services and Open Source projects. If there is a significant breaking change I suspect that they will handle it more like they handled the Angular 1 transition, where they monitored demand, and then provided a sunset period.
This assumes that Go 2 does have significant breaking changes, which the Go team have explicitly said that they do not want to do. The current view seems to be that they will feed new features into Go 1 releases as opt-ins, in the same ways that modules is an opt-in feature that will become opt-out in some future Go 1 release.
