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

11–20 of 92 posts

Re: Rust CLI with Clap

#11

Post by jvanderbot »

msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

If you got a progress bar, website, and dependency tree for every

#include , , , or

it'd feel pretty crazy too. Imagine if `make` went out and pulled latest upstream changes for `pthreads` every time any one of your dependencies used it. C++ imagine it's pulling and building boost, or abseil.

C#? The entire mono/.net toolchain and system/ FFI libraries.

Imagine if we had "dot-h.io" that tracked how many separate C projects used argp. Laughable! Millions!

Every language has gobs of dependencies. So many dependencies it'd make you sick. Thousands upon thousands of lines of code, just to make something that runs on one target and says "Hello world" to the screen. Hell, some languages require you to run a runtime on your operating system that runs on real hardware _just to launch those thousands of lines of code_. And those are written using curl.h, pthreads.h, etc etc (or similar). Bananas!

At least those with package managers allow you to see it, audit it, update it seamlessly.

If it's too big, use "nostd"

Re: Rust CLI with Clap

#12

Post by hamandcheese »

deathanatos wrote: post #9
msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

… I don't want every program to attempt to implement argument parsing; bespoke implementations will be lower quality than clap. Not reinventing an argument parser is an extremely reasonably dependency to take. Clap, on the non-derive side, has approximately two dependencies: anstream/anstyle (for terminal coloring, another thing that sounds deceptively simple at first pass, if you think all the world is a VT100, but…

I agree with you that this is a ridiculous criticism to level against clap specifically.

But I also share the same overall sentiment. Every moderately sized rust project I've worked on has quite a lot of transitive deps, and that makes me a little bit nervous.

Re: Rust CLI with Clap

#13

Post by msgodel »

jvanderbot wrote: post #11
msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

If you got a progress bar, website, and dependency tree for every #include , , , or it'd feel pretty crazy too. Imagine if `make` went out and pulled latest upstream changes for `pthreads` every time any one of your dependencies used it. C++ imagine it's pulling and building boost, or abseil. C#? The entire mono/.net toolchain and system/ FFI libraries. Imagine if we had "dot-h.io" that tracked how many separate C pr…

I shouldn't have to and will not explain why C's stdio.h and arbitrary 3rd party projects on github are not the same.

Re: Rust CLI with Clap

#14

Post by dietr1ch »

msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

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.

Re: Rust CLI with Clap

#15

Post by hamandcheese »

I like clap a lot, however I find that clap derive is not very easily discoverable. I always have to google for the right macro incantation to get what I want. Whereas editor completions from rust analyzer get me quite far without needing to leave my editor when I'm just using an ordinary library.

I think this is more a criticism of rust-analyzer than clap itself, any macro-heavy library I have similar issues with.

(Yes I know clap can be used without derive, but I'm willing to deal with the pain to parse directly into a struct)

Re: Rust CLI with Clap

#16

Post by rendaw »

msgodel wrote: post #10
deathanatos wrote: post #9

Earlier quoted context omitted.

… I don't want every program to attempt to implement argument parsing; bespoke implementations will be lower quality than clap. Not reinventing an argument parser is an extremely reasonably dependency to take. Clap, on the non-derive side, has approximately two dependencies: anstream/anstyle (for terminal coloring, another thing that sounds deceptively simple at first pass, if you think all the world is a VT100, but…

This shouldn't even need terminal coloring, in fact that sounds annoying because it's going to have to behave differently if you pipe it to less (or it's going to do something dumb like the rust compiler itself and just reopen the tty.) This actually reminds me of my other issue with this kind of "oh we just get it for free" attitude that tends to result in overbuilding things that I also dislike in rust. No I think…

Why is needing to behave differently when you pipe annoying? Are you saying it doesn't work? But also FWIW I don't think piping command help output is a common use case.

Re: Rust CLI with Clap

#17

Post by msgodel »

rendaw wrote: post #16
msgodel wrote: post #10

Earlier quoted context omitted.

This shouldn't even need terminal coloring, in fact that sounds annoying because it's going to have to behave differently if you pipe it to less (or it's going to do something dumb like the rust compiler itself and just reopen the tty.) This actually reminds me of my other issue with this kind of "oh we just get it for free" attitude that tends to result in overbuilding things that I also dislike in rust. No I think…

Why is needing to behave differently when you pipe annoying? Are you saying it doesn't work? But also FWIW I don't think piping command help output is a common use case.

It's useful if your terminal emulator isn't very good and the scrollback buffer doesn't work. This can happen for any number of reasons.

Or maybe I don't feel like using the mouse, or I want to do something like grep it. There are an unlimited number of reasons I might want that, that's how interfaces like these work.

Re: Rust CLI with Clap

#18

Post by rendaw »

hamandcheese wrote: post #15

I like clap a lot, however I find that clap derive is not very easily discoverable. I always have to google for the right macro incantation to get what I want. Whereas editor completions from rust analyzer get me quite far without needing to leave my editor when I'm just using an ordinary library. I think this is more a criticism of rust-analyzer than clap itself, any macro-heavy library I have similar issues with. (…

I hope you don't mind me plugging my thing here, but I had the 100% same problem and made aargvark (https://docs.rs/aargvark/latest/aargvark/). When I was using clap, every time I'd need to look up how to do X, or what combination of things I needed to put an enum here, or find out that this nesting of data types wasn't supported, etc.

It's still derive macro-based, but there's only one derive (`Aargvark`) rather than `Parser`, `Subcommand`, etc, and it can handle any data structure composition orthogonally (although crazy structures may result in fairly awkward command lines).

Re: Rust CLI with Clap

#20

Post by hamandcheese »

dietr1ch wrote: post #14
msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

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 needing to pull in any libraries. But in rust you need a library for even a basic http request.

Post reply on HN