mow.cli

how would you compare this to something like https://github.com/jawher/mow.cli ?

May I suggest you give https://github.com/jawher/mow.cli a look/try ? Disclaimer: I'm the author of mow.cli ;)

Thanks for citing mow.cli [1] and glad you're liking it! And you are spot-on regarding closures: it was a design choice made expressly for the purpose of being able to: - scope command specific flag and args, instead of having one giant catch-all context map - declare real and typed Go variables instead of something like context.String("--option") - use the same pattern as the flag std package (flag.Bool, etc.) which I liked a lot Disclaimer: I am the author of mow.cli [1] https://github.com/jawher/mow.cli

Interesting article but I am not sure about the recommendation of writing your own command parsing instead of using something like mow.cli[1] which seems fairly lightweight and self-contained. In terms of logging I am also wondering if something like zerolog[2] might be a better choice than go-kit's logger given its higher performance [1] https://github.com/jawher/mow.cli [2] https://github.com/rs/zerolog

docopt() does few things and does them well: * parse the call arguments and split them into options and arguments * perform a very basic validation, i.e. handle the options which take a value and those who don't Granted, mow.cli is much more complex. But it also does much more: * Generate contextual help message * Enforce arbitrarily complex validation rules (see the cp example) in your stead, meaning less code (and bugs) for you to write * Does the routing, i.e. you don't need to have multi-level switch/case and if/else blocks to select and execute the correct code path based on the input arguments. I talked about this in a previous article [1]. And finally, the library user doesn't have to deal with all this complexity: this is an implementation detail which I thought would interest technical readers, hence blogging about it. You as a u