4 ms·

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

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. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell me what's impacted by the upgrade. Giving developers more information when upgrading libraries will go a long way towards making "update your libraries" a regular housekeeping task.

mseepgood 6y ago
> 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.
Ericson2314 6y ago
Gah in every language I want that interface comparison tool, and I keep on being disappointed.
- jbamsterdam 6y ago
  Until gorelease is ready, you can try apidiff (https://go.googlesource.com/exp/+/refs/heads/master/cmd/apidiff/ https://go.googlesource.com/exp/+/refs/heads/master/cmd/apid...).
- Ar-Curunir 6y ago
  rust-semverver does what you want for Rust, I think?
  - Nemo157 6y ago
    It would if it worked, but every time I've tried using it I've hit some combination of crashes and weird false positives.
jbamsterdam 6y ago
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.
jrockway 6y ago
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.
merb 6y ago
btw. this blog is about binary/source compatibility, which is a fucking hard problem in nearly EVERY language. (maybe not in javascript tough)
arp242 6y ago
"Argumentum ad generics"

mseepgood 6y ago

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

Ericson2314 6y ago

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

jbamsterdam 6y ago
Until gorelease is ready, you can try apidiff (https://go.googlesource.com/exp/+/refs/heads/master/cmd/apidiff/ https://go.googlesource.com/exp/+/refs/heads/master/cmd/apid...).
Ar-Curunir 6y ago
rust-semverver does what you want for Rust, I think?
- Nemo157 6y ago
  It would if it worked, but every time I've tried using it I've hit some combination of crashes and weird false positives.

jbamsterdam 6y ago

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.

jrockway 6y ago

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.

merb 6y ago

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

arp242 6y ago

"Argumentum ad generics"