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

41–50 of 92 posts

Re: Rust CLI with Clap

#41

Post by porridgeraisin »

iloveyoudearly wrote: post #34
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…

Not sure if it's on par with Clap, but for Python I don't see enough people talk about SimpleParsing: https://github.com/lebrice/SimpleParsing It has quirks once you try to do something more complex/advanced, but for most of the simple stuff it's very nice to use.

Nice. I had made something similar (but less featureful), funnily enough also for an ML training script usecase. Here it is in a gist:

https://gist.github.com/porridgewithraisins/313a26ee3b827f73...

I love the ergonomics of this method, and I was going to improve it to support subcommands, etc, but now I think I will use the library you posted.

Re: Rust CLI with Clap

#42

Post by ModernMech »

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…

  No help generation
  Only flags, options, free arguments and subcommands are supported
  A properer parser would knew that --arg2 is a key and will return an error, since the value is missing.
  If such behavior is unacceptable to your application, then you have to use a more high-level arguments parsing library.
Yeah, no thank you. If we're talking about 700 LOC, I'm just going to write it myself rather than take on a dependency that won't even describe itself as a proper enough parser. This argument parser doesn't even handle the tedium of generating a help message for the user, and doesn't really parse the arguments -- what's the purpose of using it to do the argument parsing then?

So 700 LOC gets us a mediocre argument parser with no features. What do you get for an additional 9300 LOC? A "properer" parser (dev and user experience+). Help generation (dev experience+). Multiple interfaces (dev experience+). Color terminal output (user experience+). Suggested completions (user experience+).

Is it worth it? I dunno that's a per-project choice. If you absolutely need the smallest footprint and compile times possible, probably you don't want to go with clap. You also probably don't want to go with Rust.

Re: Rust CLI with Clap

#43

Post by dietr1ch »

hamandcheese wrote: post #20
dietr1ch wrote: post #14

Earlier quoted context omitted.

If all the code was crammed into the std library it'd be fine? Functions need to build on top of simpler functions to be able to abstract problems and tackle them one at a time. There's innate complexity around and without trying to tame it into smaller functions/packages it seems you'll end up in a worse spot.

Not OP, but more code in stdlib does indeed sound better. I'm not against abstraction and re-use. What I don't like is that for every given thing I want to do, there are multiple crates that offer the same functionality, and it can be really fatiguing trying to vet them. And it is truly a rarity to find a crate that is past the 1.0 version milestone. Compare to golang for example. You can get quite far in go without…

Trying to get everything into std requires a lot of work that I think gets harder when considering Rust's goals of being low level and paying only for what you use. Not having finalised some aspects of the language itself would also slow this down even more.

I'd rather have libraries built with more freedom and the possibility of having experimental stuff around meanwhile the std worthy solution lands, and if things work fine without them in the standard library then it makes sense to keep them out.

Rust may be lacking an easier way to shop for recommended libraries for common problems. There should be a path to discover all the good and best libraries for each problem. crates.io takes a stab at having this information, but I think more handholding and some sort of community seal of approval is needed.

Re: Rust CLI with Clap

#44

Post by [deleted] »

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…

[deleted]

Re: Rust CLI with Clap

#45

Post by lmm »

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…

> Why would you default to the biggest, slowest option?

Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

Re: Rust CLI with Clap

#46

Post by 1vuio0pswjnm7 »

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.

Re: Rust CLI with Clap

#47

Post by csnover »

qaq wrote: post #39
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…

Hmm isn't optimizing to save 690KiB for an optimised release binary and getting incremental builds to be significantly less than 400ms actually much closer to the after-mentioned "every web site must be able to scale like Facebook” type logic" ?

No, it is the following the principle of YAGNI.

Re: Rust CLI with Clap

#48

Post by kstrauser »

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…

That 690KB savings is 1/97000th of the RAM on the machine I develop and run most of my Rust software on.

If I ever encounter a single howto or blog post or Stack Overflow answer that tells me how to use Clap to do something 5 minutes more quickly than with an alternative, it’s paid for itself.

Amdahl’s Law says you can’t optimize a system by tweaking a single component and get more than that component’s total usage back. If Clap takes 1% of a program’s resources, optimizing that down to 0 will still use 99% of the original resources.

It’s just not worth it.

Re: Rust CLI with Clap

#49

Post by never_inline »

kstrauser wrote: post #48
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…

That 690KB savings is 1/97000th of the RAM on the machine I develop and run most of my Rust software on. If I ever encounter a single howto or blog post or Stack Overflow answer that tells me how to use Clap to do something 5 minutes more quickly than with an alternative, it’s paid for itself. Amdahl’s Law says you can’t optimize a system by tweaking a single component and get more than that component’s total usage b…

At this point you're just flexing that you have 96GiB machine. (Average developer machines are more like 16GiB)

But that's not the point. If every dependency follows same philosophy, costs (compiler time, binary size, dependency supply chain) will add up very quickly.

Not to mention, in big organizations, you have to track each 3rd party and transitive dependency you add to the codebase (for very good reasons).

Re: Rust CLI with Clap

#50

Post by never_inline »

iloveyoudearly wrote: post #34
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…

Not sure if it's on par with Clap, but for Python I don't see enough people talk about SimpleParsing: https://github.com/lebrice/SimpleParsing It has quirks once you try to do something more complex/advanced, but for most of the simple stuff it's very nice to use.

People are used to the `click` way, where you can define args as function parameters. It's little more verbose but it helps click is a very established library which also provides many other things needed by CLI tools.

There's also `typer` from the creator of `fastapi` which relies on type annotations. I have not had the opportunity to use it.

Post reply on HN