51–57 of 57 posts
Earlier quoted context omitted.
Gah in every language I want that interface comparison tool, and I keep on being disappointed.
rust-semverver does what you want for Rust, I think?
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: https://blog.merovius.de/2015/07/29/backwards-compatibility-...
I use Go daily and one of the aspects which is always a challenge is equality checking. From the post, > 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…
What the go team fails to realize is that they haven't actually reduced complexity in their design of go; they've simply MOVED it. And it's been moved in unintuitive ways as they've painted themselves into corners that should have been avoidable with some careful planning. We now have: - magic file names - magic directory names - magic comments - magic env vars - API design requires gymnastics and juggling since recu…
I know about one use for it: package mypackage_test allows you to exclude test code from builds. I agree with the rest of your points though :)
Earlier quoted context omitted.
I was really thinking about the problem described by GP. But in any case: - Type safe enumerations - Generics (lets see if flyweight design actually makes it) I'll give you both those. Generics would be the killer feature for me. - package names that don't depend on source locations Java package structure mirrors the file system, no? - binary packages for proper encapsulation and even faster builds Go package binarie…
> Java package structure mirrors the file system, no? No, it mirrors the directory structure, from import location, without any reference to DNS servers or source code repositories. All in all Go is a Java 1.0, with all plus and minus that it entails.
The big difference is you have to place the code in the $GOPATH with the right directory structure and disable mod (GO111MODULE=off)
Earlier quoted context omitted.
It's the most over-though versioning system ever actually. It's a rare mixture of NIH syndrome and obsession to a specific theoretical concern. Yes semver dependency management is NP-hard[1], but lawn mowing is NP-hard too, and yet that doesn't seem to stop anyone else! [1] in fact it's only NP-hard if you add an optional aditionnal constraint: that every dependency must have a single instance even if it's a transiti…
Yet asking Glide or Dep to solve semver for a typical medium-sized Go service would peg your CPU fans for an hour or two and usually fail.
https://www.reddit.com/r/golang/comments/7c1dj9/the_real_rea...
Of all the package systems I've worked with, I've had the least about of trouble with Go modules. Some aspects can be a bit confusing and idiosyncratic as first, but overall I found it quite easy to understand and reason about (which is important especially when things go wrong! I still remember my "I can't figure this out, fuck it, I'll rm -rf shit until it works"-Bundler days all too vividly).
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 m…