== In Go I've given up and I'm now using standard packages

In my Go programming, I've come around to an attitude that I'll
summarize as 'there's no point in fighting city hall'. What this means
is that I'm now consciously using standard packages that I don't
particularly like just because they are the standard packages.

I'm [[on record GoGetoptProblem]] as disliking the standard _flag_
package, for example, and while I still believe in [[my reasons
for this ../unix/UnixVsGoogleGetopt]] I've decided that it's
simply not worth going out of my way over it. The flag package
works and it's there. Similarly, I don't think that the _log_
package is necessarily a great solution for emitting messages from
Unix style command line utilities but in [[my latest Go program
https://github.com/siebenmann/ffox-remote/]] I used it anyways.  It
was there and it wasn't worth the effort to code _warn()_ and _die()_
functions and so on.

Besides, using _flag_ and _log_ is standard Go practice so it's going
to be both familiar to and expected by anyone who might look at my code
someday. There's a definite social benefit to doing things the standard
way for anything that I put out in public, much like most everyone uses
_gofmt_ on their code.

In theory I could find and use some alternate getopt package
(these days the go to place to find one would be [[godoc.org
http://godoc.org/?q=getopt]]). In practice I find using external
packages too much of a hassle unless I really need them. This is an
odd thing to say about Go, considering that it makes them so easy and
accessible, but depending on external packages comes with a whole set
of hassles and concerns right now. I've seen [[a bit too much breakage
https://twitter.com/thatcks/status/524384481273450497]] to want that
headache without a good reason.

(This may not be a rational view for Go programming, given that Go
deliberately makes using people's packages so easy. Perhaps I should
throw myself into using lots of packages just to get acclimatized to
it. And in practice I suspect most packages don't break or vanish.)

PS: note that this is different from the people who say you should eg
use the _testing_ package for your testing because you don't really
need anything more than what it provides and stick with the standard
library's HTTP stuff rather than getting a framework. As mentioned, I
still think that _flag_ is not the right answer; it's just not wrong
enough to be worth fighting city hall over.

=== Sidebar: Doing standard Unix error and warning messages with _log_

Here's what I do:

.pn prewrap on
>  log.SetPrefix("<progname>: ")
>  log.SetFlags(0)

If I was doing this better I would derive the program name from
_os.Args[0]_ instead of hard-coding it, but if I did that I'd have to
worry about various special cases and no, I'm being lazy here.