3 ms·

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

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.

deathanatos 1y ago
… 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 really isn't; this is a reasonable dep. for a CLI arg parser) and strsim (string similarity, again, a reasonable dep for a CLI arg parser…). And that's it¹ for clap's direct deps. (¹I'm omitting clap_lex, as an "internal" dep.) On the derive side, there's the usual proc-macro2/quote/syn trio, but those come up frequently in derive crates due to what they do, and other than that, there's just `heck`, which is again an obvious dependency in context. … what is so quizzical to me about the "so many dependencies!" complaint is that when we do get examples like this, they're almost always on crates that bottle up genuinely tricky functionality (like what we see here) — exactly the sort of thing that a.) is hard to get right and b.) isn't relevant to the problem I want to solve. That's like "absolutely this is a dependency" central, to me…
- msgodel 1y ago
  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 people would be better off with a bespoke option parser actually.
  - rendaw 1y ago
    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.
    - msgodel 1y ago
      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.
      - rendaw 1y ago
        Are you saying your terminal emulator can't match on text with ansi color modifiers when searching?
        msgodel 1y ago
        Are you going to demand it when you write your program? That seems like a regression from most CLIs with bespoke option parsers I've used.
  - pksunkara 1y ago
    Actually, 1. `color` feature and thus the `anstream` dep is optional. 2. Even if you use it, it handles all the behaviour correctly regarding the piping and no color support, which is why it is a dependency in the first place. Source: I am clap maintainer
- hamandcheese 1y ago
  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.
- inferiorhuman 1y ago
  On the derive side, there's the usual proc-macro2/quote/syn trio, but those come up frequently in derive crates due to what they do, and other than that, there's just `heck`, which is again an obvious dependency in context. They're common dependencies, sure, but not necessarily the same versions. So, yeah, it's entirely possible you'll end up building multiple versions of quote/syn.
jvanderbot 1y ago
If you got a progress bar, website, and dependency tree for every #include <argp.h>, <stdio.h>, <sstream>, or <curl.h> 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"
- msgodel 1y ago
  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.
dietr1ch 1y ago
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.
- hamandcheese 1y ago
  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.
  - msgodel 1y ago
    Yeah I was a little surprised to discover the standard library doesn't even include regex. That's kind of extreme. Even most C environments have that.
  - tucson-josh 1y ago
    I'm not the OP here, but I did write the blog post. I have mixed thoughts on how much should be part of std. I think that what we're seeing is a class of library where we could see a new level introduced to open languages like rust that sits somewhere above std, but is maintained and blessed by a broader group than just the nebulous community. Rust's separation of std from no-std is a good example of tiers that I think we could see evolve. Another example in the same category as clap would be serde and some of the specific serde implementations like serde-yaml that is now in a really painful unmaintained/forked status. Maybe these are things to push for more broadly in the rust community.
    - msgodel 1y ago
      I think Rust's std really wants to be just the runtime. Most language stds are runtime + common utilities and then often there's an extra set of common environment libraries with varying levels of distinction.
sebtron 1y ago
Completely agree. I find it crazy that this is encouraged in the very first example in the official tutorial [1]. [1] https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html#using-a-crate-to-get-more-functionality https://doc.rust-lang.org/book/ch02-00-guessing-game-tutoria...
tcfhgj 1y ago
NIHS?

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.

deathanatos 1y ago

… 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 really isn't; this is a reasonable dep. for a CLI arg parser) and strsim (string similarity, again, a reasonable dep for a CLI arg parser…). And that's it¹ for clap's direct deps. (¹I'm omitting clap_lex, as an "internal" dep.) On the derive side, there's the usual proc-macro2/quote/syn trio, but those come up frequently in derive crates due to what they do, and other than that, there's just `heck`, which is again an obvious dependency in context. … what is so quizzical to me about the "so many dependencies!" complaint is that when we do get examples like this, they're almost always on crates that bottle up genuinely tricky functionality (like what we see here) — exactly the sort of thing that a.) is hard to get right and b.) isn't relevant to the problem I want to solve. That's like "absolutely this is a dependency" central, to me…

msgodel 1y ago
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 people would be better off with a bespoke option parser actually.
- rendaw 1y ago
  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.
  - msgodel 1y ago
    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.
    - rendaw 1y ago
      Are you saying your terminal emulator can't match on text with ansi color modifiers when searching?
      - msgodel 1y ago
        Are you going to demand it when you write your program? That seems like a regression from most CLIs with bespoke option parsers I've used.
- pksunkara 1y ago
  Actually, 1. `color` feature and thus the `anstream` dep is optional. 2. Even if you use it, it handles all the behaviour correctly regarding the piping and no color support, which is why it is a dependency in the first place. Source: I am clap maintainer
hamandcheese 1y ago
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.
inferiorhuman 1y ago
On the derive side, there's the usual proc-macro2/quote/syn trio, but those come up frequently in derive crates due to what they do, and other than that, there's just `heck`, which is again an obvious dependency in context. They're common dependencies, sure, but not necessarily the same versions. So, yeah, it's entirely possible you'll end up building multiple versions of quote/syn.

jvanderbot 1y ago

If you got a progress bar, website, and dependency tree for every #include <argp.h>, <stdio.h>, <sstream>, or <curl.h> 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"

msgodel 1y ago
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.

dietr1ch 1y ago

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.

hamandcheese 1y ago
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.
- msgodel 1y ago
  Yeah I was a little surprised to discover the standard library doesn't even include regex. That's kind of extreme. Even most C environments have that.
- tucson-josh 1y ago
  I'm not the OP here, but I did write the blog post. I have mixed thoughts on how much should be part of std. I think that what we're seeing is a class of library where we could see a new level introduced to open languages like rust that sits somewhere above std, but is maintained and blessed by a broader group than just the nebulous community. Rust's separation of std from no-std is a good example of tiers that I think we could see evolve. Another example in the same category as clap would be serde and some of the specific serde implementations like serde-yaml that is now in a really painful unmaintained/forked status. Maybe these are things to push for more broadly in the rust community.
  - msgodel 1y ago
    I think Rust's std really wants to be just the runtime. Most language stds are runtime + common utilities and then often there's an extra set of common environment libraries with varying levels of distinction.

sebtron 1y ago

Completely agree. I find it crazy that this is encouraged in the very first example in the official tutorial [1]. [1] https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html#using-a-crate-to-get-more-functionality https://doc.rust-lang.org/book/ch02-00-guessing-game-tutoria...

tcfhgj 1y ago

NIHS?