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

October 24, 2014

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 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>: ")

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.

Comments on this page:

By dozzie at 2014-10-24 09:54:44:

This attitude should apply as well to all the other programming platforms.

I see the opposite in Ruby world: for even the dumbest job programmers seem to use more or less random gems out there, whatever happens to be present on This way programmer:

  • makes it burdensome to make a package with the application (so the app could be installed in any other way than "run ./", e.g. with no network access, or in chroot, or just plain apt-get install foo on few dozens of machines)
  • gives away the control over what bugs pop out and how to deal with them

That's why I generally avoid using external libraries for mundane tasks in C, Perl, Python or Erlang.

By Jeremy at 2014-10-24 10:42:47:

Could you expand on your comment about the testing package? I did a quick search of your archives and didn't come up with anything relevant.

It sounds like you're saying that while it's not worth fighting city hall on the flags package, it is worth it for testing. If so, is it because the testing package is wrong somehow or just incomplete?

(I have much less experience than you, but my take is that it's very incomplete, but suitable for extension. But I also dislike the explosion of alternative extensions).

By cks at 2014-10-24 12:34:39:

I think I was unclear on testing, so let me try again. In the general Go world there was initially a bunch of people who developed more featureful packages for code testing and more featureful packages for web applications. Lately the general Go world has been turning away from this approach on the grounds that you don't actually need the extra stuff, with a number of people writing articles and so on.

This 'you don't need extra bells and whistles' view is a potential reason to also turn away from replacing flag and log. However it's not the reason that I'm now going to stick with flag. I still think that flag should be replaced; I've just given up 'fighting' the standard package set.

Written on 24 October 2014.
« The clarity drawback of allowing comparison functions for sorting
The difference in available pool space between zfs list and zpool list »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Oct 24 01:15:57 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.