[skybrian]

It is easier. On the other hand, Java doesn't drop any deprecated API's either, so static types may not help as much as you think. Migration still has to happen before dropping something.

It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, sometimes) have moved on.

So in a way, Python 3 helps you if all you care about is stability, since people will make changes to 3 and you can keep using 2.7.

[reality_czech]

The risk/reward ratio is a lot different in those two cases. If a Java library drops support for some API (and many do, in major versions), I will know at compile time, and fix it. If the same thing happens in Python, you may not know until days have gone past and your program crashes. The type system is like a set of unit tests that get written automatically and have 100% coverage.

There is also the issue of how code gets installed on the system. The Python model is that you have a bunch of py files sprinkled throughout the filesystem. In this case, you have a "baling out the ocean with a teaspoon" issue when making a major change. There has to be a flag day when everything changes at once. In contrast, with Go, I can have apps compiled with Go 1.0, Go 1.1, and Go 1.2 co-existing happily on the same system. They don't share library files. (Yes, I understand abut things like virtualenv, but that doesn't help distributions that want to ship your software.)

A big part of why Sun (and now Oracle) has been so conservative about backwards compatibility in Java proper (as opposed to the libraries and ecosystem) is because JDK upgrades have a similar "baling out the ocean with a teaspoon" property. It's all or nothing... you generally only have one version of Java installed, and it has to play nice with everything. If they had integrated the runtime into the binary like Go did, this would be much less of an issue.

[kazagistar]

I would go one step further: in an effort to maintain binary compatibility, Java ended up trying to do "type erasure with generics", which in my mind is a horrible wart. C# went through the same changes, and built two different libraries for collections to accommodate it.

What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.

[reality_czech]

Well, Go isn't Java. They are two different languages.

The Java designers wanted jars to be runnable by any virtual machine, ever. This meant preserving some pretty old and nasty hacks (like erasure for generics) to allow old jars to work with new virtual machines.

With Go, you would just recompile and that would be it. Go doesn't even support loadable modules yet (although it's coming soon), so they can do whatever they want with compat. It's unlikely they'll make the same mistakes Java did because they are not blinded by the "write once, run anywhere" ideology.