Live data from Hacker News

Using Go for Scalable Operating System Analytics

blog.kolide.com

11–12 of 12 posts

Re: Using Go for Scalable Operating System Analytics

#11

Earlier quoted context omitted.

Yeah.. I like cobra, but it seems to somewhat force you into using a lot of globals to accomplish things. The only downside to the oklog-style seems to be that you can't introspect the full cli tool at runtime, which rules out things like outputting documentation or shell completion files.

cobra / viper are nice, but to me they are a fair bit more heavyweight than mow. With mow also due to closures it seems easier to manage without globals, at least for programs where you don't also need a config file (which is where cobra / viper shines) but just simple cli it seems easier than rolling your own unless you just have one or two options.

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

Re: Using Go for Scalable Operating System Analytics

#12
post #11

Earlier quoted context omitted.

cobra / viper are nice, but to me they are a fair bit more heavyweight than mow. With mow also due to closures it seems easier to manage without globals, at least for programs where you don't also need a config file (which is where cobra / viper shines) but just simple cli it seems easier than rolling your own unless you just have one or two options.

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…

no problem and thanks for creating it! I also enjoyed how easy it is to extend it to support, say, enums: it was just a matter of adding flag interface support to my type and calling app.VarOpt to set it up, very straightforward
Post reply on HN