5 ms·

All those crates are actually the main thing bothering me about Rust. I've seen some fairly trivial code bases that pull down north of 1 GB of barely necessary

by fhd2 5y ago

All those crates are actually the main thing bothering me about Rust. I've seen some fairly trivial code bases that pull down north of 1 GB of barely necessary dependencies (a couple of wrappers and utilities). It's not quite as bad as NPM land where some people add a dependency for left padding a string, but dunno... Probably a fairly unpopular take, but I kinda always liked that about C/C++ code bases (that avoid hidden dependencies): It makes you realise the cost of dependencies :P So while Rust eliminates a lot of foot guns from C/C++, IMHO it introduces a major one.

berkut 5y ago
Likewise... I'm more and more finding myself either either looking for less-popular and more minimal crates (that don't need Async, or tens of other further deps), and even writing my own things for certain simple stuff (the latter often reinforced by wanted to experiment and learn). I'm more concerned about many 'critical' (because there's nothing like them in the standard library, i.e. 'rand', 'chrono') and well-recommended crates are still not at version 1.0.0, so technically they could change the API... (they won't/can't, but seems a very odd situation to me).
- jacobmischka 5y ago
  What makes you say they can't?
  - berkut 5y ago
    Well, I'm assuming it would break a lot of code...
    - jacobmischka 5y ago
      That's what semantic versioning is for?
      - berkut 5y ago
        https://semver.org/#how-do-i-know-when-to-release-100 https://semver.org/#how-do-i-know-when-to-release-100 Pretty much everyone's using chrono and rand, as there's not really anything else...
        jacobmischka 5y ago
        I'm not sure what that link is supposed to mean in this context. Yes, they should have released 1.0 sooner. That doesn't change the fact that they may want to make a breaking change in the future and bump the major version number. Tokio is the de facto async runtime, used by many (though not as many as rand and chrono surely, but still), and they've bumped major versions. Some projects still use old versions, which is actually much more problematic since multiple async runtimes usually can't exist simultaneously, but things are still mostly fine overall.
andi999 5y ago
It probably needs some more time to catch up with NPM...
- oblio 5y ago
  Unlikely to ever happen. Learning Rust is a major time investment. Basic Javascript? Not so much. They'll just draw different crowds.
- IshKebab 5y ago
  I don't think that will happen. Rust is much harder than JavaScript, so anyone who wants to write dumb one-liner packages is probably going to still be writing JavaScript and anyone who has managed to learn Rust will already be good enough not to need them.
krom 5y ago
Pay attention to cargo features for crates. (Those are flags for crates, which also affect the dependency set needed by the crate affected.) A lot of crates have a bunch of selectable features. Their defaults usually lead to many dependencies needed. If you carefully select those, you can cut down on dependencies a lot. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html
- deleted 5y ago
  [deleted]
- fhd2 5y ago
  Great tip! I wasn't quite aware, basically like compile flags with C/C++ deps (implemented somewhat similar to Cargo in Gentoo, I'd say).
  - eska 5y ago
    A recent update also made the resolution of such features smarter in the case that the same dependency is used by multiple dependencies, so the size has been reduced. There's also tooling for investigating your dependencies, automatic git bots to make suggestions, etc.
    - jamwaffles 5y ago
      Built into `cargo`, I'd recommend `cargo tree`, `cargo tree -i` and/or `cargo tree --duplicates` to figure out where certain types of dependency tree bloat are.
lordnacho 5y ago
There's tools that show you the dependency tree, forwards and backwards. I was pleasantly surprised that it existed and was so simple. I've seen cpp codebases where people just copy paste the libs because they don't like struggling with cmake. Then there's boost, which is huge. Maybe a bit less relevant in recent versions but still, once you need it... From a security perspective you may have a point, if it's security critical maybe think about that. But then also security benefits from rust in other ways. My main focus is ergonomics: how simple is it to grab a lib, how often do unforeseen issues happen? With CPP I just get this feeling every time that this is a cave entrance, and adding this lib that I know I need might just eat up a whole day of googling. It doesn't happen every time of course, it just has happened enough times that I'm fearful. With Rust it hasn't happened yet. Something in general about it is that errors seem to make sense. You get a message, and the hint is an actual hint that helps solve the problem. This goes for using libs as well as the language in general.
natded 5y ago
Comparing Cargo package management to NPM is just silly. You can pull all the crates from crates.io and scan them for memory unsafety with Cargo and Rudra. I don't think anything similar is possible to do with C++ for example, let alone JS. The alternative would be to arbitrarily slow down library development by including them in STD which is silly for many reasons (ie. it would hurt ecosystem, it would hurt the actual library development, it would hurt the STD development).
- pas 5y ago
  npm automatically does a "security audit" when you install packages. it's not a panacea, but a pretty big help.

by fhd2 5y ago

berkut 5y ago

Likewise... I'm more and more finding myself either either looking for less-popular and more minimal crates (that don't need Async, or tens of other further deps), and even writing my own things for certain simple stuff (the latter often reinforced by wanted to experiment and learn). I'm more concerned about many 'critical' (because there's nothing like them in the standard library, i.e. 'rand', 'chrono') and well-recommended crates are still not at version 1.0.0, so technically they could change the API... (they won't/can't, but seems a very odd situation to me).

jacobmischka 5y ago
What makes you say they can't?
- berkut 5y ago
  Well, I'm assuming it would break a lot of code...
  - jacobmischka 5y ago
    That's what semantic versioning is for?
    - berkut 5y ago
      https://semver.org/#how-do-i-know-when-to-release-100 https://semver.org/#how-do-i-know-when-to-release-100 Pretty much everyone's using chrono and rand, as there's not really anything else...
      - jacobmischka 5y ago
        I'm not sure what that link is supposed to mean in this context. Yes, they should have released 1.0 sooner. That doesn't change the fact that they may want to make a breaking change in the future and bump the major version number. Tokio is the de facto async runtime, used by many (though not as many as rand and chrono surely, but still), and they've bumped major versions. Some projects still use old versions, which is actually much more problematic since multiple async runtimes usually can't exist simultaneously, but things are still mostly fine overall.

andi999 5y ago

It probably needs some more time to catch up with NPM...

oblio 5y ago
Unlikely to ever happen. Learning Rust is a major time investment. Basic Javascript? Not so much. They'll just draw different crowds.
IshKebab 5y ago
I don't think that will happen. Rust is much harder than JavaScript, so anyone who wants to write dumb one-liner packages is probably going to still be writing JavaScript and anyone who has managed to learn Rust will already be good enough not to need them.

krom 5y ago

Pay attention to cargo features for crates. (Those are flags for crates, which also affect the dependency set needed by the crate affected.) A lot of crates have a bunch of selectable features. Their defaults usually lead to many dependencies needed. If you carefully select those, you can cut down on dependencies a lot. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html

deleted 5y ago
[deleted]
fhd2 5y ago
Great tip! I wasn't quite aware, basically like compile flags with C/C++ deps (implemented somewhat similar to Cargo in Gentoo, I'd say).
- eska 5y ago
  A recent update also made the resolution of such features smarter in the case that the same dependency is used by multiple dependencies, so the size has been reduced. There's also tooling for investigating your dependencies, automatic git bots to make suggestions, etc.
  - jamwaffles 5y ago
    Built into `cargo`, I'd recommend `cargo tree`, `cargo tree -i` and/or `cargo tree --duplicates` to figure out where certain types of dependency tree bloat are.

lordnacho 5y ago

There's tools that show you the dependency tree, forwards and backwards. I was pleasantly surprised that it existed and was so simple. I've seen cpp codebases where people just copy paste the libs because they don't like struggling with cmake. Then there's boost, which is huge. Maybe a bit less relevant in recent versions but still, once you need it... From a security perspective you may have a point, if it's security critical maybe think about that. But then also security benefits from rust in other ways. My main focus is ergonomics: how simple is it to grab a lib, how often do unforeseen issues happen? With CPP I just get this feeling every time that this is a cave entrance, and adding this lib that I know I need might just eat up a whole day of googling. It doesn't happen every time of course, it just has happened enough times that I'm fearful. With Rust it hasn't happened yet. Something in general about it is that errors seem to make sense. You get a message, and the hint is an actual hint that helps solve the problem. This goes for using libs as well as the language in general.

natded 5y ago

Comparing Cargo package management to NPM is just silly. You can pull all the crates from crates.io and scan them for memory unsafety with Cargo and Rudra. I don't think anything similar is possible to do with C++ for example, let alone JS. The alternative would be to arbitrarily slow down library development by including them in STD which is silly for many reasons (ie. it would hurt ecosystem, it would hurt the actual library development, it would hurt the STD development).

pas 5y ago
npm automatically does a "security audit" when you install packages. it's not a panacea, but a pretty big help.