trace-moe-go VS cobra

The Cobra package is designed for building modern CLI applications. It supports subcommands, nested flag sets, command aliases, and generates help text automatically. It’s especially useful for CLI tools with multiple commands and a deeper structure.

Here is one of your empty argument being thrown away instead of respected bugs:

* https://github.com/spf13/cobra/blob/6dec1ae26659a130bdb4c985...

I could explain the single-quote argument quoting error if you were running it on Windows. The Go runtime library does not provide single-quoting on Windows. At all. (This is historically the behaviour of C runtime libraries on Windows, too.) It should be using a proper argument vector and not doing its own command-line parsing on other platforms, though.

* https://cs.opensource.google/go/go/+/master:src/os/exec_wind...

* https://cs.opensource.google/go/go/+/master:src/os/proc.go;l...

### When to Use Viper Use Viper for **applications with complex configurations**, like microservices or CLI tools. For simple scripts, environment variables alone might suffice. ## Comparing the Libraries Here’s a quick table to help you decide which library fits your needs. | Library | Use Case | Key Feature | Performance | Learning Curve | |---------|----------|-------------|-------------|----------------| | Gin | Web APIs | Routing | High | Low | | Testify | Testing | Assertions | N/A | Low | | Zap | Logging | Structured | High | Medium | | GORM | Databases| ORM | Medium | Medium | | Viper | Config | Flexibility | N/A | Low | ## Tips for Getting Started - **Start Small**: Try one library at a time in a side project. - **Read Docs**: Each library has excellent documentation (linked above). - **Join Communities**: Check GitHub issues or Go forums for tips. - **Experiment**: Use the example code as a base and tweak it. ## What’s Next? These libraries are just the tip of the iceberg. Once you’re comfortable, explore others like [Cobra](https://github.com/spf13/cobra) for CLI tools or [sqlx](https://github.com/jmoiron/sqlx) for lightweight database access. The Go ecosystem is vast, and combining these tools can help you build robust, scalable applications. Pick one library, try the example, and see how it fits your workflow. Happy coding!

Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that

This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.

For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod

If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).

I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though

Then, I wanted to bring my team to the Go experience at the office as sometimes we need to deliver apps to systems on which we don't want or can't install new softwares : so delivering a static binary thanks to Go and goreleaser seemed a good option for effortless cross-compilation... and of course build the best possible UX thanks to Cobra.

Cobra https://github.com/spf13/cobra uses https://github.com/spf13/pflag, which supports GNU style flags. Cobra has been developed for many years now and has a ton of additional features, like automatically generating the autocompletions and has tons of unit tests.

I'd just use cobra.

You did a really great job describing the project and documenting it in the README. Congrats. The project looks super clean and professional.

That being said, TBH I don't see any real scenario where I would "prototype a CLI". Unlike a GUI where elements can be placed in some places vs others, a CLI is a CLI.

For any developer, it would probably take less time to write it directly using one of the libraries listed here : https://bloomberg.github.io/stricli/blog/intro (TS/JS) or https://github.com/spf13/cobra (Go) with stub implementations for commands.

The main problem for me is that defining the CLI in a JSON file lacks all the flexibility of code (reusability, etc.).

Spec duplication: the paths, the schemas etc need to be replicated on the client side again. eg when using the popular Cobra lib for Go, one must tell it all the possible types beforehand.

I really enjoyed a lot the resulting prototype I manage to get within almost 2 hours and it gave me the confirmation that I wanted to spend more time to make a clean code and lear more about Go best practices and probably use Cobra.dev (A Framework for Modern CLI Apps in Go) to learn while building something fun yet useful.

4. Cobra