3 ms·

I've become a fan of https://github.com/jessevdk/go-flags https://github.com/jessevdk/go-flags (also enjoyed structopt which is similar for Rust). I much prefer

I've become a fan of https://github.com/jessevdk/go-flags https://github.com/jessevdk/go-flags (also enjoyed structopt which is similar for Rust). I much prefer defining the flags statically on a type which stores them after rather than building it all up programmatically. Otherwise, I'm not really sure what this offers that alternatives don't, apart from the -a 1 2 3 -> [1,2,3] business which seems highly confusing and undesirable to me so I'd think of it as more of an anti-feature.

mway 2y ago
Also a fan of go-flags, I use it by default most of the time (unless the use case is so basic that the stdlib flags usage would be sufficiently simple). I think my only real point of "frustration" (mild at best) is that flag composability isn't always possible (eg embedding/sharing common non-root flags across flag structs), IIRC struct tag eval doesn't reach nested types. Other than that though, it's one of those nice libraries that just does a thing and gets out of your way.
- CamouflagedKiwi 2y ago
  Hmmmm I thought that sharing a common type did work in the way you would expect it to? I haven't tried embedding with it though I don't think. TBH I rarely do it much anyway, mostly the flag struct ends up being one anonymous struct which is operated on in the main package only. I do like writing custom types for parsing though - I've seen engineers do a bunch of post-hoc parsing logic which generally just ends up being messy.
cedws 2y ago
Struct tags = reflection, and reflection is nasty. They also aren't validated at compile time. Liberal use like this should be avoided.
- quacker 2y ago
  In what way is reflection nasty? What compile-time validation do I actually lose by using struct tags for CLI arg parsing?
  - cedws 2y ago
    Reflection is slow and bug prone. Struct tags are widely considered in the Go community to be a nasty hack yet a necessary evil. They should be used at little as possible because if you mess them up you don't get a compile error, you get a runtime error.
    - 9rx 2y ago
      > Reflection is slow Beware of microbenchmarks, but in my tests the above package only added around 0.001 ms over the standard library flag package. Even if real world usage increases that by several orders of magnitude, it isn't going to matter. No human will ever notice.
- CamouflagedKiwi 2y ago
  Do you also avoid using packages like encoding/js, which make equally liberal use of struct tags and reflection?
  - cedws 2y ago
    encoding/json does not make liberal use of struct tags, it uses only one. It's also battle tested and lives in the standard library. I don't have faith in many other projects to get bug-prone reflection code right.
    - CamouflagedKiwi 2y ago
      It does have a microformat within that single tag though ("x,omitempty" etc) so there is a bit more complexity than 'just one tag' indicates. Anyway, I think you're overstating how hard reflection-based code is. Yes, it is tricky and should mostly be avoided, but it's not beyond the scope of human intellect to understand (especially Go's which is pretty sensible).

mway 2y ago

Also a fan of go-flags, I use it by default most of the time (unless the use case is so basic that the stdlib flags usage would be sufficiently simple). I think my only real point of "frustration" (mild at best) is that flag composability isn't always possible (eg embedding/sharing common non-root flags across flag structs), IIRC struct tag eval doesn't reach nested types. Other than that though, it's one of those nice libraries that just does a thing and gets out of your way.

CamouflagedKiwi 2y ago
Hmmmm I thought that sharing a common type did work in the way you would expect it to? I haven't tried embedding with it though I don't think. TBH I rarely do it much anyway, mostly the flag struct ends up being one anonymous struct which is operated on in the main package only. I do like writing custom types for parsing though - I've seen engineers do a bunch of post-hoc parsing logic which generally just ends up being messy.

cedws 2y ago

Struct tags = reflection, and reflection is nasty. They also aren't validated at compile time. Liberal use like this should be avoided.

quacker 2y ago
In what way is reflection nasty? What compile-time validation do I actually lose by using struct tags for CLI arg parsing?
- cedws 2y ago
  Reflection is slow and bug prone. Struct tags are widely considered in the Go community to be a nasty hack yet a necessary evil. They should be used at little as possible because if you mess them up you don't get a compile error, you get a runtime error.
  - 9rx 2y ago
    > Reflection is slow Beware of microbenchmarks, but in my tests the above package only added around 0.001 ms over the standard library flag package. Even if real world usage increases that by several orders of magnitude, it isn't going to matter. No human will ever notice.
CamouflagedKiwi 2y ago
Do you also avoid using packages like encoding/js, which make equally liberal use of struct tags and reflection?
- cedws 2y ago
  encoding/json does not make liberal use of struct tags, it uses only one. It's also battle tested and lives in the standard library. I don't have faith in many other projects to get bug-prone reflection code right.
  - CamouflagedKiwi 2y ago
    It does have a microformat within that single tag though ("x,omitempty" etc) so there is a bit more complexity than 'just one tag' indicates. Anyway, I think you're overstating how hard reflection-based code is. Yes, it is tricky and should mostly be avoided, but it's not beyond the scope of human intellect to understand (especially Go's which is pretty sensible).