> A little copying is better than a little dependency.
Go takes this to an extreme, though. Generics helps, but the implementation is so limiting that it doesn't help much.
> The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope.
Some (most) of the go code I've seen where I work suffers from Enterprise Java style identifiers. That is, TheyAreGenerallyTooLongAndIHateThemAll.
This is probably because Go doesn't allow function overriding. You can't have `streamFromUrl(foo)` and `streamFromUrl(foo, bar)`, so you end up with `streamFromUrlWithFoo(foo)` and streamFromUrlWithFooAndBar(foo, bar)`.
Right. It's kosher to have one simple "New(..)" function per package, for the key type in the package, but all the other constructors shall have verbose names.
There is a group of developers where I work who would take a perfectly fine `New(…*Options)` constructor and write a whole suite of “option wrapper” “utilities” around it, rather than expose that function. It makes me tear up a little (not in a good way).
"A little copying is better than a little dependency" is not talking about anything that would be solved by generics or metaprogramming, which suggests that you are completely misunderstanding. It's saying to not import a large library if you only need one five line helper function from it. Generics do not help, and the advice could be applied to any programming language.
Go takes this to an extreme, though. Generics helps, but the implementation is so limiting that it doesn't help much.
> The general rule of thumb is that the length of a name should be proportional to the size of its scope and inversely proportional to the number of times that it is used within that scope.
Some (most) of the go code I've seen where I work suffers from Enterprise Java style identifiers. That is, TheyAreGenerallyTooLongAndIHateThemAll.