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.
> 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.
https://blog.golang.org/toward-go2