Recommendation for a simple cli arg parser?

I've struggled along a bit with the most commonly-used library, but I find it entirely bewildering. The Rust community seems to have an impressive tolerance for complexity. Maybe they're just all 50x developers (which does seem to be the primary Rust audience).

Anyway I'm a simple soul, so can someone recommend me a cli arg parser that covers the basics (required args plus long and short form options/flags; no hierarchical commands required), preferably including some sort of help generation.

I see there are a few on, and I'll trawl the list and make my own assessment, but does anyone have recommendations from experience?

I'm assuming you're referring to clap as the most commonly used library? If I ever need something simpler I usually reach for argh.

If you can more precisely state your difficulty with, I presume, clap you'll probably get more accurate alternative suggestions and/or some help with clap itself.


I like to use StructOpt since it parses arguments right into a strongly-typed config structure.

As an aside, re:

Please refrain from judging the entire community. If you are having difficulty with something, feel free to ask for help, but stating that all things Rust are excessively complicated just for the sake of it is neither productive nor justified.


Won't it be essentially the same as clap v3?

Cheers, that looks like it has potential, I'll take a look. The name certainly expresses something of my sometimes frustrated response (so far) to the Rust ecosystem!

If I had a single problem that's just what I'd do. But in this particular case, it's been such a constant stream of difficulties I'd spend more time posting than using.

Fair enough. I actually do think there's a presentation vs reality problem in this respect re Rust, but I expressed myself carelessly in momentary irritation so I'll leave that aside there.

Yes it seems that clap v3's derive features came from StructOpt, which is now in maintenance mode as a result

FWIW, I ended up staying with clap, because I found the excellent Discussions · clap-rs/clap · GitHub. I had missed this when first surveying the repo & docs, but it has many well (and very patiently) explained answers. I found it more useful than the docs.


I usually use clap, but when I want something simple, I love pico-args!

Doesn't do a lot out of the box but I found it to be very much enough for simple stuff, and is intuituve.


Cool thanks. I think I'm settled on clap for this immediate purpose, but I'll stash this for future reference.

I have written a simple cli tool with the library argparse, may be you can try it.

Once you figure it out it is kind of easy. There are some things that might trip you. One that comes to mind that gets me is if you put doc comments on your struct they end up in the binary program in the help output.

This reminds me of a knee-jerk reaction I used to have when encountering a large codebase at work for the first time.

You see loads of layers of indirection and code that seems to make no sense except to make the author look clever, and think to yourself, "geez, this is massively overengineered! All it needs to do is X".

Then you start to learn about the history of the project and the list of things the code is being asked to do and realise it's actually about as complex as it needs to be given the circumstances.

Notice I didn't mention any languages here - the project I'm referring to was written in Delphi. Often the code is complex because the problem is complex[1], and actually once you look a bit closer you realise it wasn't that complex after all.

  1. In your case, clap is trying to encapsulate most of the ways command-line arguments have been implemented, while also providing nice things like good quality help text and completion generation. You get all these things for free, so 9 times out of 10 it's enough to slap a #[derive(clap::Parser)] and a couple other attributes on your Args struct and call it a day (example). ↩︎

1 Like

Not at all. I'm not inexperienced, and my reaction isn't actually the one you're outlining. Though that's entirely my fault, as the clumsy expression (not the reaction) did come in a moment of irritation (not the best time to post, I'd agree). I chose not to expand on it as it seemed like an unnecessary aside. But as we're here ...

On the clap issue - the 'tolerance for complexity' I note doesn't refer to the necessary complexity of a mature cli args library that can do much (and has matured with the language), but rather that such a library is the one recommended everywhere, to everyone (it's literally the only such library I've come across in all tutorials etc, and have only heard of any others others at all in this thread). It's clearly far more complex than is needed for many, probably most, apps. That complexity is tolerated.

On the 'presentation vs reality' question re Rust more generally, again, it's not that I believe Rust to be too complex for what it needs to do. It's rather that I don't believe the common presentation ('Systems programming for everyone'), born out of a laudable normative desire for inclusivity, reflects reality. I suspect it's not for everyone, and probably not for those of us at the lower end of the developer ability pecking order.

My guess (and it's not much more than that) is that those who strongly hold this view probably have a limited experience of the true breadth of the world of professional software development. If you've only worked with people who've studied CS at serious universities, and then worked at FAANGS or SV startups, and think HN is a reasonable reflection of the dev world at large, you probably have a limited perspective on the range of abilities extant in professional software development.

1 Like

To be fair, clap is (in)famously large, even uncomfortably so.

That, I agree with. No matter how inclusive the community is, or how good the docs are, or how intuitive the language is, there still is, and I believe, there will always be a significant amount of effort that one needs to put into learning a language, ecosystem, or programming paradigm (let alone "the entirety" of software development in general, if at all such a thing exists). There is simply no way one could possibly be spoon-fed every last bit of information one needs to be a productive, creative, experienced, insightful software engineer.

And indeed, unfortunately, for some people this remains very far from reality. Some simply aren't willing to put in the required effort. Some would be but aren't interested enough. For others, maybe it just exceeds their mental capacity. Yet others don't have the time or opportunity or other resources to pursue it. No profession is going to be literally for everyone, ever. We can and should try to make technologies more accessible, but expecting that literally anyone can be a programmer, or a musician, or a doctor, or a Formula 1 driver, or a teacher is… simply not realistic. (And for the record, I don't think that the Rust team is that naïve – they are probably merely trying to be encouraging.)


A month or so later, and having done a steady trickle of work on the project I had in mind here, I've found dealing with clap by far the most difficult (not to mention time-consuming) work involved so far. I have several times found myself avoiding refining the UI because figuring out how to change anything to do with commandline args has been so daunting. And not once have I managed to do so by reading the clap docs, which I can scarcely make head or tail of. I think I would have been able to work from the docs had I made the in retrospect more sensible decision to go with the Builder rather than the Derive API, so I guess that's on my Rust-inexperienced head.

This isn't a criticism of clap per se - it's obviously extremely capable, and the extent of its capacities likely dictate some complexity (though I do wonder whether its API couldn't be refined). But I think the fact that this is the de facto default args parser (or at least the most commonly-recommended one) must say something about the Rust community and its tolerance for complexity (for good or ill, or more likely both in different domains).

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.