Not necessarily. Java currently ships two date libraries, for example: java.util.Date and java.time.*. There are some duplicating classes like Vector from the old times and ArrayList from new times. There are two I/O frameworks: old I/O (File, FileInputStream, etc) and nio (Path, FileSystem, etc). While I don't like the particular way Java did that, basically you just have to ship all old versions and keep them working and ship new versions with some adapters to ease migration.

> Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements.

> You can't have it both ways,

You can have a continuously improving platform with full backward compatibility, and all the improvements that aren't just efficiency of established operations are opt-in.

I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?

> Please correct me if I am wrong but I believe golang is essentially complete, right

I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again.

The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages.

Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.

Go is not complete. But it does not evolve by revolution as of now.

Complete is hard to define, no language stops evolving. But Go language is perfectly suitable for large projects, and is pretty much my Go-to nowadays. (Pun intended)