Good article on the whole, but I have a few quibbles:
> If your repo foo is primarily a binary, put your library code in a lib/ subdir, and call it package foo.
IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo.
I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/.
I think that inline config objects should be used with useful zero values to try to emulate Lisp's or Python's keyword arguments: if one always needs to provide a value for each config object member, then just use arguments after all.
I think a testing library can be a great addition, since it can turn a three-line if check into a one-line assertion.
> If your repo foo is primarily a binary, put your library code in a lib/ subdir, and call it package foo.
IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo.
I also think that anything which has commands other than a single-command project which will always be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/.
I think that inline config objects should be used with useful zero values to try to emulate Lisp's or Python's keyword arguments: if one always needs to provide a value for each config object member, then just use arguments after all.
I think a testing library can be a great addition, since it can turn a three-line if check into a one-line assertion.