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.
Java to Go - two extremes, too bloated to too simplistic - I'd look for something between. If your projects aren't interesting an interesting language can help you endure. If your projects and your language isn't interesting then tedium.
Java can be remarkably bloat-free if you so choose. The problem is that in most places where Java is used, it's used because of its stability, ergo that stability mentality will be pervasive and the code base will probably be huge and old.
But if you have a greenfield project and some decent Java developers, you'd be surprised what you can do with Java if you're willing to avoid the common pitfalls (J2EE, Spring).
You needn't worry about Go being too simplistic for much longer. It looks like they're going to add a bloated form of generics soon, with something called "contracts" that's almost the same as "interfaces" but a little different. A few versions back, Go added "aliases" of types, but it was almost aliases of anything -- only intense community pressure prevented that bloat. And having had a special rule in its short-form declarations to make error handling a little terser, Go is looking at bringing another syntactic shortcut called "handle-check" to bring a little more error-handling tersity. Go's simplicity will be gone in a few short years.
It took 10 years to move the needle on generics and better error handling, and the draft solutions for both still smell of minimum usefulness/minimum complexity in the language. Whether that's a good approach is up to the individual, but I don't see Go 2 ending up as some unwieldy monstrosity.
I'm curious how the proposal for generics is "bloated" - especially as compared to something like C# or Rust.
Just because the currently-proposed Go generics is less bloated than those of C# and Rust doesn't mean it isn't "bloated" compared to Go 1.11. And I wouldn't call the description of contracts in the discussion document from last month "minimum complexity".
What happens when a company steps up and says, "we now offer commercial support for Golang"? Do you suddenly apply the same rationale because someone might download their commercial version of Go by accident?
