Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust CLI with Clap

tucson-josh.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Rust CLI with Clap

#71

Post by sshine »

csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

> I got a nickel every time I spent 15 minutes replacing a trivial use of clap with pico-args and thus reduced the binary size and compile time of some project by at least 80%, I would have at least three nickels.

Hahaha, awesome. Thanks for the pico-args recommendation.

It supports the bare minimum.

I sure would like deriving-style parsing and --help auto-generation.

I think deriving-style unavoidably causes build time and complexity.

But it could be done without the dependency explosion.

There's a list of options here:

https://github.com/rosetta-rs/argparse-rosetta-rs#rust-arg-p...

Among the ones you recommend, argh supports deriving, auto-generates --help and optimizes for code size. And its syntax is very comparable to clap, so migrating is very easy. gumdrop seems very similar in its feature set (specifying help strings a little differently), but I can't find a defining feature for it.

Re: Rust CLI with Clap

#72

Post by theknarf »

csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

Convenience always win. If we want smaller more purposefully built dependencies then we need better tooling that makes those choices convenient.

Re: Rust CLI with Clap

#73

Post by csnover »

qaq wrote: post #69
csnover wrote: post #47

Earlier quoted context omitted.

No, it is the following the principle of YAGNI.

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…

> But in your case, you’re investing time upfront to avoid a heavier dependency

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/

Re: Rust CLI with Clap

#74

Post by wonger_ »

ben0x539 wrote: post #4

structopt/Clap's derive magic is one of the first things I miss when I go to write some more-or-less trivial program in a non-Rust language these days. Being able to define all the data for a command line argument in one place (how/where to store it, what the type/valid input is, the association between the name and a variable/field, the documentation for --help...) seems like table stakes but afaict almost every oth…

Docopt is great! http://docopt.org/

There's implementations for other languages, too.

TIL about structopt, thanks.

Re: Rust CLI with Clap

#75

Post by fainpul »

PowerShell has everything related to argument parsing, helptext generation, tab completion, type coercion, validation etc. built-in with a declarative DSL. Many things work even directly OOTB, without requiring special annotations.

It is by far the nicest way to create CLI tools I have ever seen. Every other shell or commandline parsing library I ever tried, feels extremely clunky in comparison.

https://learn.microsoft.com/en-us/powershell/module/microsof...

Re: Rust CLI with Clap

#76

Post by sshine »

1vuio0pswjnm7 wrote: post #46
csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

Rust invites serious disregard for resources and time. Sadly, many will accept that invitation. But some won't.

> disregard for resources and time

There is a tradeoff between compile time and running time.

This matters for programs that run more often than they get compiled.

Re: Rust CLI with Clap

#77

Post by mprovost »

I chose clap as the argument parsing crate for my book on Rust CLI programming and it's been my biggest regret. Folk sometimes complain that Rust itself is a moving target but I haven't found that to be the case at all. On the other hand, clap has gone through several, incompatible major releases over the past few years. Unfortunately, in order to keep this forward momentum, it also starts deprecating things which means that I had to pin it to a quickly outdated version. If I ever go back and update the earlier chapters I'd pick a simpler, slower-moving library.

On the other hand, this situation is a great example of why keeping things like argument parsing out of the Rust standard library is such a good idea. It's much better to let the community gel around some crates which are able to iterate (and innovate) faster than something with strict backwards-compatibility requirements. Looking at the discussion here there's clearly not one way to solve this - there's no way that something as large and complex as clap has evolved into will ever become "standard".

Re: Rust CLI with Clap

#78

Post by MrJohz »

csnover wrote: post #73
qaq wrote: post #69

Earlier quoted context omitted.

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…

> But in your case, you’re investing time upfront to avoid a heavier dependency 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…

Neither of those libraries provide cross-shell completions, or coloured output, or "did you mean" suggestions, or even just command aliases, all of which I would consider basic features in a modern CLI. So you need to invest more time to provide those features, whereas they just exist in clap.

That's not to say that clap is always better, but it is significantly more full-featured than the alternatives, and for a larger project, those features are likely to be important.

For a smaller project, like something you're just making for yourself, I can see why you'd go for a less full-featured option, but given there's not much difference between clap and, say, argh that I feel like I'd get much benefit out of argh. If you're really looking for something simple, just use lexopt or something like that, and write the help text by hand.

Re: Rust CLI with Clap

#79

Post by Fluorescence »

mprovost wrote: post #77

I chose clap as the argument parsing crate for my book on Rust CLI programming and it's been my biggest regret. Folk sometimes complain that Rust itself is a moving target but I haven't found that to be the case at all. On the other hand, clap has gone through several, incompatible major releases over the past few years. Unfortunately, in order to keep this forward momentum, it also starts deprecating things which me…

Seems unfair. Version 4 was almost 3 years ago and and I can't recall any issue in that time.

Major versions have good quality migration guides. If only all libraries were developed with such professionalism.

https://github.com/clap-rs/clap/blob/v4.5.0/CHANGELOG.md

Re: Rust CLI with Clap

#80

Post by MrJohz »

b0a04gl wrote: post #38

10kloc for command line parsing. TEN THOUSAND LINES. pico-args does it in 700 lines and probably handles 99% of real world use cases. compile times go to shit binary size bloats and for some edge case you'll never hit.most CLI tools need what three four flags max, maybe a subcommand or two. you don't need the swiss army knife of argument parsing for that. tried replacing clap with pico-args on three different project…

Honestly, if you're doing something so small, even pico-args is a lot more than you need. Just use lexopt, and you get a very simple match-based DSL for defining your arguments, that even neatly sidesteps the limitations provided in pico.
Post reply on HN