Also: getopt is pretty easy to write (if you're going for strict Unix style, you're presumably not looking for a featureful getopt), and that interface style is abused far more often than it's deployed gracefully. Some of the worst Unix command line interfaces† are the product of getopt, or the belief that there's an idiomatic Unix argument handling convention and that the idiom is getopt.
If your argument parsing needs are complicated, you should break out an actual parser.
Finally: I see the benefit of having an auto-generated usage message that is better than a bad auto-generated usage message, but if you really want artisanal command line tools, shouldn't you be writing artisanal usage messages? C programmers as a rule didn't count on the library to generate the usage message for them.
I think this is missing the point of the article. The author doesn't seem to care too much about complicated argument parsing needs, just about the interface that Go's flag library presents to the user.
You touch on the auto-generated usage message: personally I think the one that Go's flag lib generates is terrible. I agree wholeheartedly with the author. C programmers indeed don't count on libc to generate the usage mechanism (though, frankly, if it did, I certainly wouldn't mind), but we're talking about Go programmers here. And if idiomatic Go is to use the flag library, then you get an auto-generated message. And it's bad.
I think the other part of the author's gripe is just as (if not more) important: flag has decided to do away with the difference between '-' and '--' options, something everyone has come to expect as standard. In the Go model, it's weird to have multiple options for the same thing. For frequent users, typing "rm -rf" is better and easier than "rm -r -f", which is still better than (what I would think Go would encourage) "rm --recursive --force". The short options (and ability to chain them without a dash per option) is great for command-line users, and the long options are great for scripts where you want clarity and self-documentation.
Being able to make up complicated parsing rules is potentially another problem, sure, but I don't think it's as important to users of a Go program as either of the above issues that the author raises.
(For the record, I absolutely love Python's argparse. I think they've settled on a fair compromise between giving a lot of power, but making the simple cases simple, while providing behavior and UI that most users of my programs would expect. Not perfect, but I've been happier with it than with any other parsing library. Of course, implementing an API like that in a non-dynamic language that doesn't support optional, named function arguments might be difficult or impossible.)
But why should you have to do extra work to override a default that's sub-optimal from a standardization and user-familiarity standpoint, and is trivial to fix "upstream" where everyone should benefit?
I think the ideal argument parser allows you basically to write a spec for your program, and then automatically generates a parser that will both turn options specified by the user into a map, as well as print the relevant parts of the spec when invalid input is given.
Could you elaborate on why you believe flag is preferable to something like what I've described? (I'm coming from Ruby-land where Trollop basically does that.) I'm struggling to understand what's preferable about needing to roll your own parser and write documentation when you could just describe your program and have the parser/documentation auto-generated.
Trollop seems like a "better getopt". Conceptually it's still a series of flags. For simple programs, flags might be all you need, and there's value in cohering with all other Unix tools that communicate strictly through flags.
But when your needs get more complicated, when the information being communicated on the command line starts getting more dense, the concept "flags" becomes an obstacle. Far too many programs keep leaning on flags far past the point where the abstraction breaks down. You start to feel like you're writing small programs in the confining language of command line flags.
A great example I think is "tcpdump", because it exhibits both behaviors: it has a hideously overcomplicated getopt configurator and a relatively graceful parsed language for describing capture filters (those filters being the most important option given to tcpdump). You can see how tcpdump would be better off if most of the flags were hoisted into that filter language.
(They can't easily be, of course, because that filter language is actually parsed --- and then compiled --- by libpcap, not tcpdump).
What I'm saying is that flag feels like a "worse getopt," and you seem to be going from the assumption that if you need more than 2 flags you should roll your own DSL parser, which sounds to me overengineered and harder for others to pick up. Most programs are not tcpdump.
It's OK for the standard library to satisfice or even constrain flag parsing, because programs that need "complicated flag parsing" are better served by something more sophisticated than flags anyways. Super-awesome flag libraries just trick programmers into building bad UX.
A lot of programs would also be better off if they reduced the numbers of flags they had, and made the "value" of those flags more sophisticated. In other words: taking some of the weight off the flag parser.
Most programs aren't tcpdump. Most programs don't have a lot of flags. But most programs that do have a lot of flags would probably be better off with something other than flags as their command line idiom. "tar" springs to mind.
It's hard for me to look at my zshrc and see all the aliases with their -fNqC's and -avz's and think "this is a good command line user experience". Many of these flaggy CLI programs have terrible UX.
There's maybe a "Gettysburg Address In Powerpoint"-style satire to be done of, say, awk commands expressed entirely in flags.
Also: getopt is pretty easy to write (if you're going for strict Unix style, you're presumably not looking for a featureful getopt), and that interface style is abused far more often than it's deployed gracefully. Some of the worst Unix command line interfaces† are the product of getopt, or the belief that there's an idiomatic Unix argument handling convention and that the idiom is getopt.
If your argument parsing needs are complicated, you should break out an actual parser.
Finally: I see the benefit of having an auto-generated usage message that is better than a bad auto-generated usage message, but if you really want artisanal command line tools, shouldn't you be writing artisanal usage messages? C programmers as a rule didn't count on the library to generate the usage message for them.
† See for instance nmap