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 as disliking the standard flag
package, for example, and while I still believe in my reasons
for this 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 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). 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 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:
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.
|
|