Keeping your Go modules compatible

&gt; When you run into a case where you want to add a method to an existing interface, you may be able to follow this strategy. Start by creating a new interface with your new method, or identify an existing interface with the new method. Next, identify the relevant functions that need to support it, type check for the second interface, and add code that uses it.<p>I like this pattern, and I have used it. The issue I have is when I look at the generated godoc, the original interface is in the signature. I don&#x27;t know the function accepts the new interface as well without either digging into the code or a comment for the function.

I use Go daily and one of the aspects which is always a challenge is equality checking. From the post,<p>&gt; There is one subtle way a new field can break user code unexpectedly. If all the field types in a struct are comparable—meaning values of those types can be compared with == and != and used as a map key—then the overall struct type is comparable too. In this case, adding a new field of uncomparable type will make the overall struct type non-comparable, breaking any code that compares values of that struct type.<p>From experience, this is non-trivial to avoid in a long lived codebase.<p>It’s telling that 99% of the codegen tools used in Go, e.g. protobuf, thrift, Gorm, etc. all output an isEqual method of some kind.

there&#x27;s something that I just don&#x27;t get about golang modules, I don&#x27;t know what it is but they don&#x27;t click with me<p>it might well be something tacit that golangers learn from each other directly? or otherwise it&#x27;s so obvious and simple and I just haven&#x27;t realized?<p>it feels like it&#x27;s the kind of thing that just clicks one day possibly after a few years

What the go team fails to realize is that they haven&#x27;t actually reduced complexity in their design of go; they&#x27;ve simply MOVED it. And it&#x27;s been moved in unintuitive ways as they&#x27;ve painted themselves into corners that should have been avoidable with some careful planning.<p>We now have:<p>- magic file names<p>- magic directory names<p>- magic comments<p>- magic env vars<p>- API design requires gymnastics and juggling since recursive imports are disallowed<p>- A ton of useful code in the standard library remains unlayered and unexposed for no good reason (pprof, for example)<p>- Requiring full paths rather than relative imports complicates everything when you&#x27;re fetching it from a different source location (replace directives and magic ENV vars).<p>- Slice implementation means that you need to do double pointer storage to keep track of the same slice from multiple places<p>- Creating arrays with a dynamically defined length is horribly overcomplicated<p>- Their policy on warnings and instead calling every little thing an error is terrible and wastes a ton of developer time.<p>- Lack of runtime const value support is just sloppy.<p>- Why do go source files even need a package declaration? It serves no useful purpose since the compiler already knows enough to spit out an error if you get it wrong.<p>- Refactoring across packages is nearly impossible to automate because there&#x27;s no way to declare adherence to an interface.<p>- No importing of test code from other test code (which means that the import code in the compiler has increased complexity to enforce this silly rule).<p>- Stack overflows are STILL impossible to track down (after a DECADE!) because it only prints the top of the stack, which is useless in such a case.<p>- Linting is too opinionated and is all-or-nothing.<p>------------------<p>I could go on. I really wanted to like go, and many parts of it do actually feel nice. But even after a decade it&#x27;s a huge mess. I&#x27;ve spent more time writing workarounds for go than for any other language in my 25 year career. Hell, I even modified the damn compiler out of frustration! [1]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;go#the-go-programming-language" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kstenerud&#x2F;go#the-go-programming-language</a>

Has something changed such that adding an exported field to a struct is now safe in the case of clients who are using struct embedding? Previously: <a href="https:&#x2F;&#x2F;blog.merovius.de&#x2F;2015&#x2F;07&#x2F;29&#x2F;backwards-compatibility-in-go.html" rel="nofollow">https:&#x2F;&#x2F;blog.merovius.de&#x2F;2015&#x2F;07&#x2F;29&#x2F;backwards-compatibility-...</a>

Reading these blog posts, you get see Go&#x27;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.<p>For the record, I&#x27;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&#x27;s impacted by the upgrade. Giving developers more information when upgrading libraries will go a long way towards making &quot;update your libraries&quot; a regular housekeeping task.