|
|
|
|
|
by qaq
351 days ago
|
|
The “every website must scale like Facebook” mindset is premature optimization driven by hypothetical future needs exactly what YAGNI advises against. But in your case, you’re investing time upfront to avoid a heavier dependency that already works and has no clear downside for the majority of users. If you don’t actually need ultra-small binaries or sub-200ms compile times, then replacing Clap just in case seems like a textbook case of violating YAGNI rather than applying it. |
|
This is very confusing to me. What of this API[0], or this one[1], requires “investing time upfront”? With argh, you already know how to use all the basic features before you even start scrolling. These crates are all practically interchangeable already with how similarly they work.
It is only now that I look at clap’s documentation that I feel like I might understand this category of reply to my post. Why does clap need two tutorials and two references and a cookbook and an FAQ and major version migration guidelines? Are you just assuming that all other command-line parsers are as complicated and hard to use as clap?
[0] https://docs.rs/argh/latest/argh/
[1] https://docs.rs/gumdrop/latest/gumdrop/