3 ms·
You're not wrong with your point, even if your example is. Go has made many breaking changes that still kept compiling, and compiling seems to be the thing they
by TheDong 5y ago
You're not wrong with your point, even if your example is. Go has made many breaking changes that still kept compiling, and compiling seems to be the thing they care about the most. Cribbing from a previous comment I've made... https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324
1. go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS
2. net/http started defaulting to http/2 for the same methods, an obviously breaking change
3. go1.17 switched to silently truncating a lot of query strings https://go.dev/play/p/azODBvkb-zK https://go.dev/play/p/azODBvkb-zK
4. Check out 'PreferServerCipherSuites' on tls.Config. https://pkg.go.dev/crypto/tls#Config https://pkg.go.dev/crypto/tls#Config ; of course that was a breaking change.
There's a few other things like this littered throughout the go stdlib, and I've personally hit far more breaking changes in Go's stdlib than the "go 1 compatibility promise" would have you expect.
- pcwalton 5y agoThanks, I knew I had seen other examples other than the one I cited but had forgotten what they were.
- Mawr 5y ago> go 1.9 adding monotonic clock readings in a breaking way, i.e. this program changed output from 1.8 to 1.9: https://go.dev/play/p/Mi6cGCPd0rS https://go.dev/play/p/Mi6cGCPd0rS That's not a breaking change, if you were comparing Times with just "==" before 1.9, your program was broken as well: From the 1.8 source [1]: // Equal reports whether t and u represent the same time instant. // Two times can be equal even if they are in different locations. // For example, 6:00 +0200 CEST and 4:00 UTC are Equal. // Do not use == with Time values. func (t Time) Equal(u Time) bool { return t.sec == u.sec && t.nsec == u.nsec } [1]: https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/time/time.go;l=75 https://cs.opensource.google/go/go/+/refs/tags/go1.8:src/tim...
- TheDong 5y agoIt was not until go1.8 that they added the warning to not use '=='. In go 1.7, it simply told you that == vs Equal had different semantics, see https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/time/time.go;l=67-71 https://cs.opensource.google/go/go/+/refs/tags/go1.7:src/tim... There are many cases where you know that your times are in the same timezone, or you don't mind different timezones comparing as different, and so '==' used to work correctly quite often. My program was clearly not broken in 1.7, when I followed the documentation "Equal ignores location, == uses location", and things worked well. My program became counter to their documentation in 1.8. My program broke in 1.9. I don't see how that is not a breaking change.
- Mawr 5y agoYeah, you're right. I didn't think to check previous versions. It seems to me like a flaw in the language that "==" can compare unexported struct fields. Looks like it's possible to disallow comparing structs with "==" at compile time: https://go.dev/play/p/BfM6sDxlTq9 https://go.dev/play/p/BfM6sDxlTq9. Not ideal, but better than nothing I suppose.
- Mawr 5y ago> Looks like it's possible to disallow comparing structs with "==" at compile time. But of course, then such structs cannot be used as map keys: https://go.dev/play/p/JXzqHPInJ-G https://go.dev/play/p/JXzqHPInJ-G.