It's pretty to make version one of your language's libraries clean and simple. The real challenge is how they hold up over time and the needs of evolution. Go's philosophy seems to be:
1. Simplicity matters more than compatibility.
2. Assume all extant Go code is easily mutable.
The purist in me finds that appealing, but I'm not sure how that will hold up over the long term. The language seems intentionally designed to not evolve which doesn't seem like a good way to stay useful for real people for a long time.
Maybe I'm wrong and everything will work out, but I wonder if several years from now, Go will just fall over from its inflexibility and become unusable.
You typically can't even compile Linux with the previous GCC version, yet somehow that kernel has been tottering along for about 20 years now.
If you compile a program using Go, you get a binary that will run forever. Statically linked, contains the runtime, you're all set. If you update Go, you can then re-build that same program, but you might have to update a few things to get a working binary again--but you only have to do this if, somehow, that originally-compiled binary isn't working for you.
If Python decides they want to change the syntax for opening a file, then you can either 1. Keep a second Python around forever for compatibility or 2. Modify your program so it uses the new syntax. Go will never do this to you; as long as your OS continues to support the same binary format, I don't see why a binary shouldn't work indefinitely.
