alt Hacker News> The actual backwards compatibility in go is achieved by never removing functionality or syntax.
The previous version removed functionality related to loop variables, so that is not strictly true. You might be right that the project doesn't take change lightly. There has to be a very compelling reason to justify such change, and why would it be any other way? If something isn't great, but still gets the job done, there is no reason to burden developers with having to learn a new language.
Go is not exactly the most in-depth language ever conceived. There is not much functionality or syntax that could be removed without leaving it inoperable. But there is no technical reason why it couldn't. The mechanics to allow it are already there, and it doesn't even violate the Go 1 guarantee to do so under the operation of those mechanics.
So, sure, it is fair to say that there is a social reason for Go making as few breaking/incompatible changes as is possible, but we were talking about the technology around allowing breaking/incompatible changes to co-exist and how the same concept could have been applied to Python. In Rust community fashion, I am not sure you have have improved on the horrible communication. We recognized that there is some difference in implementation details right from the onset, but the overall concept still seems to be the same in both cases to me.
Again, we need it dumbed down for the every day average person. Your audience doesn't eat monads for breakfast like your expression seems to believe.
> Go 1.22, for example, removed functionality related to loop variables, so that is not strictly true.
Ah, interesting. I searched but I couldn't find any example of go actually making a breaking change. Rust has a massive document [1] documenting every single breaking in single document. With go you kind of have to dig through the release notes of each version.
So, maybe Golang are relaxing their stance slightly on backwards compatibility, now that they have a mechanism that does kind of work. Which is good, I encurage that. But their offical stance is still that most code from go 1.0 should work without issues.
> there is no reason to burden developers with having to learn a new language.
To be clear, many of the breaking changes in Rust editions are the same kind of thing as that go loop example. Edge cases where it's kind of obvious that should have always worked that way, but it didn't.
The average programmer will barely notice the changes between editions, they won't have to re-learn anything. The major changes to the language usually come in regular feature releases; They are optional additions, just like go.
While the edition mechanism could be used to make changes as big as Python 3, so far it hasn't and I don't think it ever will. Decent chance there will never be a "rust 2" either.
> In Rust community fashion, I am not sure you have have improved on communicating the difference
Sigh... you aren't wrong:
----------
The difference is more attitude than anything else.
Go strives to never have breaking changes, even if they are forced to bend that rule sometimes. They do have a mechanism that allows breaking changes, but seems to be a reasonably recent innovation (before go 1.21, it wouldn't even error when encountering a future go version directive, and they didn't use it for a breaking change until 1.22)
Rust accepts that it needs to do breaking changes sometimes, and has developed mechanisms to explicitly allow it, and make it as smooth as possible. And this mechanism works very well.
----------
BTW, I'm not even saying go's stance is wrong. Rust needs this mechanism because it's a very ambitious language. It never would have reached a stable 1.0 unless it recognised the need for breaking changes.
Go is a much simpler language, with a different target market and probably should be aiming to minimise the need for breaking changes.
My original point is that "never make breaking changes" is the wrong lesson to take away from Python 3. And that Rust's editions provide a very good example of how to do breaking changes correctly.
[1] https://doc.rust-lang.org/edition-guide/editions/