Hacker News new | ask | show | jobs
by the_mitsuhiko 3620 days ago
Everybody I have ever seen do CLI applications in Go will recommend heavily against it.
1 comments
themihai 3620 days ago
The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag
link
timtadh 3619 days ago
If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher level tool would be nice but I have never found one I actually like.
link
skybrian 3619 days ago
Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.
link
the_mitsuhiko 3619 days ago
The standard package cannot be changed.
link
skybrian 3619 days ago
By "adjust to" I meant living with the standard library's decisions without changing them. Compatibility with GNU syntax doesn't seem very important.
link
timtadh 3619 days ago
Well, I am the primary user of my command line applications as they are for my research. As the primary user they better be,

1. Easy to use

2. Have standardized syntax for flags across languages

3. Be easy to maintain

4. Be well documented so that I can use them a year or 5 years from now.

My applications often have complex syntax. For instance I work in frequent pattern mining, the basic syntax for some of my programs looks like:

  program [global options] -o <output> --support=<int> \
        <datatype> [data-type-options] <path-to-data>
        <algorithm> [algorithm-options]
        <filter-chains>
        <logging-and-serialization>
Being able to tightly control how the sub-commands chain together is important to me. Support for both short (-s) and long (--long) options make it easy to write both one off commands and self documenting commands in scripts and makefiles.

I write programs in more languages than just Go, and the programs in Go need to work the same way the programs in other languages work. That means GNU option syntax, which is the superior syntax for my needs in any case.

link