4 ms·

>Go has made changes post-1.0 that were more aggressive >than anything Rust has done, such as changing the size of int. Changing the size of int shouldn't

>Go has made changes post-1.0 that were more aggressive >than anything Rust has done, such as changing the size of int. Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. Even if this isn't true, Go's release note says: >The language allows the implementation to choose whether >the int type and uint types are 32 or 64 bits. [1] The only thing that changed was the implementation, not the language. [1] https://golang.org/doc/go1.1#int https://golang.org/doc/go1.1#int

pcwalton 10y ago
> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. All of the "breaking changes" in Rust have been of this form. We're very up front about any possible breakage. When we talk about "breaking changes", we mean "a change that shouldn't be breaking, but could be breaking if code was relying on this bug/implementation-specific behavior". Those types of changes—changes that might cause breakage in practice but do not change the language definition—are often not considered "breaking changes" in Go. But in Rust we often call them "breaking changes", because we are concerned first and foremost about the practical considerations of changes we make, not just whether we are technically allowed to make them per the letter of the law.
dbaupp 10y ago
> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. Theoretically one should be using fixed-sized variables, but people may not realise they're relying on a particular behaviour. One of the whole points for using a language like Go over, say, C is that humans are imperfect and so having the computer assist is good, and this imperfection penetrates into all aspects of the software process. With a tasty name like "int" and being generally the default type, I'm sure a lot of code uses it when fixed sized types may be better. > The only thing that changed was the implementation, not the language. This is somewhat irrelevant: it still results in code not compiling or possibly changing behaviour, because people in fact have to use an implementation of Go, they don't write in an abstract idealised version of it. Rust's breaking changes are generally the same sort of thing (undocumented implementation details, changing the implementation to match the long-stated desired behaviour and bug fixes), but they still result in people's code not compiling or changing behaviour and so need to be handled as such.

pcwalton 10y ago

> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. All of the "breaking changes" in Rust have been of this form. We're very up front about any possible breakage. When we talk about "breaking changes", we mean "a change that shouldn't be breaking, but could be breaking if code was relying on this bug/implementation-specific behavior". Those types of changes—changes that might cause breakage in practice but do not change the language definition—are often not considered "breaking changes" in Go. But in Rust we often call them "breaking changes", because we are concerned first and foremost about the practical considerations of changes we make, not just whether we are technically allowed to make them per the letter of the law.

dbaupp 10y ago

> Changing the size of int shouldn't be a breaking change in Go since pointer arithmetic isn't allowed and everyone should use fixed-size variables when you're relying on this behavior. Theoretically one should be using fixed-sized variables, but people may not realise they're relying on a particular behaviour. One of the whole points for using a language like Go over, say, C is that humans are imperfect and so having the computer assist is good, and this imperfection penetrates into all aspects of the software process. With a tasty name like "int" and being generally the default type, I'm sure a lot of code uses it when fixed sized types may be better. > The only thing that changed was the implementation, not the language. This is somewhat irrelevant: it still results in code not compiling or possibly changing behaviour, because people in fact have to use an implementation of Go, they don't write in an abstract idealised version of it. Rust's breaking changes are generally the same sort of thing (undocumented implementation details, changing the implementation to match the long-stated desired behaviour and bug fixes), but they still result in people's code not compiling or changing behaviour and so need to be handled as such.