> Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world.

Nothing of this has to do with or would be better with generics.

Modules have nothing to do with comparable structs. It's just that making a comparable struct uncomparable could break users of your API, so it's something to be on the lookout for if you value backcompat. (The module system ensures that users will get the version of the code they want; you only have to worry about backwards compatibility if you expect users to upgrade to your new version.)

There are millions of ways to break users with an update that machines can't detect. For example:

Old version:

func Lt(a, b YourType) bool { return a < b }

New version:

func Lt(a, b YourType) bool { return a >= b }

This is not specific to Go.

Despite the title, the problems that this article discusses could have happened even before modules were introduced. Before modules, your only choices were to stay compatible or break users. Modules give us the freedom to make breaking changes in a safe, documented way.

btw. this blog is about binary/source compatibility, which is a fucking hard problem in nearly EVERY language. (maybe not in javascript tough)

Gah in every language I want that interface comparison tool, and I keep on being disappointed.

Until gorelease is ready, you can try apidiff (https://go.googlesource.com/exp/+/refs/heads/master/cmd/apid...).

rust-semverver does what you want for Rust, I think?

It would if it worked, but every time I've tried using it I've hit some combination of crashes and weird false positives.

"Argumentum ad generics"