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

81–90 of 92 posts

Re: Rust CLI with Clap

#81

Post by packetlost »

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…

I'll take this opportunity to plug lexopt [0] a "pathologically simple CLI opt parser" crate. While I haven't quite had the opportunity to use it, I certainly will the next time it comes up.

[0]: https://docs.rs/lexopt/latest/lexopt/

Re: Rust CLI with Clap

#82

Post by mprovost »

Fluorescence wrote: post #79
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

Yes 4 has been out for a while but I was caught in the time when it went from v2 (2020) to v3 (2021) to v4 (2022). I made the mistake of rewriting all the chapters from using 2 to 3, which was quickly deprecated for 4.

Re: Rust CLI with Clap

#83

Post by mprovost »

packetlost wrote: post #81
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…

I'll take this opportunity to plug lexopt [0] a "pathologically simple CLI opt parser" crate. While I haven't quite had the opportunity to use it, I certainly will the next time it comes up. [0]: https://docs.rs/lexopt/latest/lexopt/

Thanks that actually looks really good! Part of the challenge with some of the crates is that they're great for advanced use but there's so much magic going on with derive macros, which a new Rust programmer won't be familiar with. Most simple CLI programs don't even declare structs so you would have to take a detour to explain that first.

Re: Rust CLI with Clap

#84

Post by [deleted] »

kstrauser wrote: post #52
never_inline wrote: post #49

Earlier quoted context omitted.

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).

I can write and have written hand-tuned assembly when every byte is sacred. That’s valuable in the right context. But that’s not the common case. In most situations, I’d rather spend those resources on code ergonomics, a flexible and heavily documented command line, and a widely used standard that other devs know how to use and contribute to. And by proportion, that library would add an extra .7 bytes to a Commodore…

[deleted]

Re: Rust CLI with Clap

#85

Post by packetlost »

mprovost wrote: post #83
packetlost wrote: post #81

Earlier quoted context omitted.

I'll take this opportunity to plug lexopt [0] a "pathologically simple CLI opt parser" crate. While I haven't quite had the opportunity to use it, I certainly will the next time it comes up. [0]: https://docs.rs/lexopt/latest/lexopt/

Thanks that actually looks really good! Part of the challenge with some of the crates is that they're great for advanced use but there's so much magic going on with derive macros, which a new Rust programmer won't be familiar with. Most simple CLI programs don't even declare structs so you would have to take a detour to explain that first.

Clap is really nice for more complex CLIs, but I will agree that there's a hefty amount of magic going on that I'm not really a fan of

Re: Rust CLI with Clap

#86

Post by justinrubek »

tonyedgecombe wrote: post #59
lmm wrote: post #45

Earlier quoted context omitted.

> 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?

These decisions accumulate then all of a sudden you have a project that takes ten minutes to build for almost no benefit.

This is an incredible exaggeration. The vast majority of these projects don't even approach it. I use clap in a number of projects and they compile in just seconds.

Re: Rust CLI with Clap

#87

Post by justinrubek »

csnover wrote: post #51
lmm wrote: post #45

Earlier quoted context omitted.

> 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?

> 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? This is the logic of buying a Ford F-150 to drive your kids to school and to commute to the office because you might someday need to maybe haul some wood from the home improvement store once. The compact sedan is the obviously practical choice, but it can’t haul the wood…

These are not even remotely equivalent scenarios. If I want to remove clap as a library, I just remove it. If I buy an F150 I now have spent a lot of money and it's mostly gone so replacing it is significantly more expensive. It also burns more fuel.

Re: Rust CLI with Clap

#88

Post by justinrubek »

tcfhgj wrote: post #68
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…

Clap has also great dev ux, so I wouldn't put maintainability as an expense.

I use clap everywhere for this, but I'm not sure that I agree that it has a "great" experience. It does the job and I've no need to reach for another tool. But it can be frustrating sometimes.

Re: Rust CLI with Clap

#89

Post by tcfhgj »

justinrubek wrote: post #88
tcfhgj wrote: post #68

Earlier quoted context omitted.

Clap has also great dev ux, so I wouldn't put maintainability as an expense.

I use clap everywhere for this, but I'm not sure that I agree that it has a "great" experience. It does the job and I've no need to reach for another tool. But it can be frustrating sometimes.

Well, I can only speak for myself

Re: Rust CLI with Clap

#90

Post by johncolanduoni »

csnover wrote: post #47
qaq wrote: post #39

Earlier quoted context omitted.

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.

In engineering, principles exist to guide you toward a preferred outcome. That’s what ultimately matters, not how many times you get to write YAGNI in your commit messages.
Post reply on HN