Hacker News Reader

Comment by pcwalton | Hacker News Reader

Well, that's clearly not the way Go operates. Go makes incompatible changes between minor releases; they just don't break type signatures. For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1]. This is clearly an incompatible change, but as it didn't cause code to fail to compile the Go team deemed it semver compatible.

Edit: Apparently this is wrong! See replies below.

[1]: https://fasterthanli.me/articles/abstracting-away-correctnes...

View on HN

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

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

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

4. Check out 'PreferServerCipherSuites' on 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.

> 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

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/tim...

It 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/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.

Yeah, 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. Not ideal, but better than nothing I suppose.

> 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.

Thanks, I knew I had seen other examples other than the one I cited but had forgotten what they were.

It's worth noting that the author of that article was mistaken, there was likely some other issue with their software than what they described here. ImportedLibraries() in the pe package has never done anything other than returned nil, nil. This wasn't changed in a minor release. You can browse the source history here: https://github.com/golang/go/blame/master/src/debug/pe/file....

For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1]

I just looked at the Git history and this is plain false. It already looked that way when the big source tree move (src/pkg/ -> src/) was done in 2014. Tracing it back further (to before Go 1.0 times, when there wasn't even a builtin error interface yet and the function returned os.Error), ImportedLibraries was *never* implemented in debug/pe.

I think taking a highly abstract definition of backcompat is not useful. We need a practical definition of back compat. If there are no (or effectively no) downstream consequences of a change, it is clearly backcompat. If there are some downstream consequences, you get into judgment call territory, but it still may be worth it. We cannot create a perfect universal rule here, and Amos is a fool for holding that standard so rigidly.

Reply on news.ycombinator.com