> Although we expect that the vast majority of programs will
> maintain this compatibility over time, it is impossible to
> guarantee that no future change will break any program.
It's extremely similar to our attitude, and that of Java, etc:
> Of course, for all of these possibilities, should they arise,
> we would endeavor whenever feasible to update the specification,
> compilers, or libraries without affecting existing code.
This isn't a bad thing! My point is as I said below: every language includes some small breaking changes, even if the goal is to have very, very few of them.
Sure. My point is that this is similar to what we guarantee: the compiler used to compile some code, and now it won't. As they say, "It has therefore been disallowed in Go 1.4, which is a breaking change, although very few programs will be affected." Our breaking changes have been similar.
Rust has rfcs, and many of the "breaking changes" are in places where the implementation didn't follow the RfC. Others were in things that were never intended to compile. Its effectively the same thing.
It's extremely similar to our attitude, and that of Java, etc:
And they have in fact made such a change: https://golang.org/doc/go1.4#methodonpointertopointerThis isn't a bad thing! My point is as I said below: every language includes some small breaking changes, even if the goal is to have very, very few of them.