I use go occasionally for minor projects, and I have learned to live without generics. In a couple of projects I ended up implementing $myproj/types which expor

I use go occasionally for minor projects, and I have learned to live without generics. In a couple of projects I ended up implementing $myproj/types which exports all the data structures I want. At that point adding the types.TypeName.Min()/.Max()/... becomes natural. It's already effectively a custom struct, so I have no problem writing the helper functions to deal with them. Heck, I used to do that in C all the time anyway. However... The dependency management is my pet peeve #1. I see no problem pulling dependencies from external repositories and building them locally. That practice spans back to at least BSD ports. What I dislike is the fact that I can't specify the version or commit I want to depend on. I find that the current implementation for "go get" assumes everyone is either a hard-core hacker, always living on the edge (and sometime pushing it) - or they have a full-fledged internal repository infrastructure in place to deal with all the mirroring and continuous integration needs. Go decides internally which revision to checkout and build, using a priority list of hardcoded tag/branch names. If those are not available, it defaults to master:HEAD, /trunk or whatever equal alternative is supported by the underlying SCM. You can not specify "I want to use _this_ version, period" which is a crying shame. I understand that internally Google doesn't use go get at all. They have their own mirrored repos for everything they need during their builds. Understandable. But ignoring the well-established practice of user-specified upstream component versions is just rude. It forces some "makes sense only in very large organisation" type of practices down the developers' throats.