4 ms·

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. Besides the impact of not being

The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. Besides the impact of not being in stdlib is very low except for discovery.

Twirrim 8y ago
> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. How often do you see that actually being a problem? Rust releases new versions on a regular cadence. Just how often do you imagine the regex crate actually needs to be updated? Or how about the random number generator crate? > Besides the impact of not being in stdlib is very low except for discovery. I always find this an interesting argument. We've seen node.js etc. packages be compromised many times, or even completely vanish (left-pad)? How much confidence can I have that any individual package hasn't been compromised somehow? How much confidence can I have that random dependencies aren't suddenly going to enter my build chain. That left-pad situation was classic. So many things got broken, not because they'd picked up left-pad, but because dependencies of dependencies of dependencies relied on it (and so on down the line...) There was that situation just a month or so ago where a developer just didn't want to maintain their package any more, had someone volunteer, who then compromised it with a crypto-miner. Now on top of that licensing gets to be a whole bunch of fun as soon as you step outside the stdlib. For every crate you add, you need to do a licence audit, and for each and every one of its dependents, and its dependents dependents. Amazon, for example, has a black list of licenses. You can't use any software licensed under one of them, for whatever reason the lawyers have about each one.
- shepmaster 8y ago
  > How often do you see that actually being a problem? See my sibling comment about backwards compatibility > Just how often do you imagine the regex crate actually needs to be updated? You can see the frequency of updates to the regex crate if you are interested: https://crates.io/crates/regex/versions https://crates.io/crates/regex/versions. Sometimes a release in a few days, or a few a month. > Or how about the random number generator crate? Even more interesting, because `rand` hasn't even reached 1.0 yet! https://crates.io/crates/rand/versions https://crates.io/crates/rand/versions Specifically, the authors are still deciding the right way to architect the library for the myriad of uses that Rust has. > or even completely vanish (left-pad) In 99.99% of the cases, you cannot remove a crate from crates.io; you can only prevent new projects from adding the crate as a dependency. The other 0.01% is because of legal reasons, and there's not much to be done about that. > For every crate you add, you need to do a licence audit https://github.com/onur/cargo-license https://github.com/onur/cargo-license claims to show you the licenses of every dependency. It's required to have a license to publish to crates.io.
shepmaster 8y ago
> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. More importantly, due to Rust's backwards compatibility guarantees, you can never remove something once it has been added. I vaguely wave towards Python's 3-5 built-in "get data from a URL" libraries as an example of a bad route that this can take. The regex crate can release a backwards-incompatible version 2 without destroying the entire ecosystem since multiple versions of a crate can co-exist in the final graph of dependencies.

Twirrim 8y ago

> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. How often do you see that actually being a problem? Rust releases new versions on a regular cadence. Just how often do you imagine the regex crate actually needs to be updated? Or how about the random number generator crate? > Besides the impact of not being in stdlib is very low except for discovery. I always find this an interesting argument. We've seen node.js etc. packages be compromised many times, or even completely vanish (left-pad)? How much confidence can I have that any individual package hasn't been compromised somehow? How much confidence can I have that random dependencies aren't suddenly going to enter my build chain. That left-pad situation was classic. So many things got broken, not because they'd picked up left-pad, but because dependencies of dependencies of dependencies relied on it (and so on down the line...) There was that situation just a month or so ago where a developer just didn't want to maintain their package any more, had someone volunteer, who then compromised it with a crypto-miner. Now on top of that licensing gets to be a whole bunch of fun as soon as you step outside the stdlib. For every crate you add, you need to do a licence audit, and for each and every one of its dependents, and its dependents dependents. Amazon, for example, has a black list of licenses. You can't use any software licensed under one of them, for whatever reason the lawyers have about each one.

shepmaster 8y ago
> How often do you see that actually being a problem? See my sibling comment about backwards compatibility > Just how often do you imagine the regex crate actually needs to be updated? You can see the frequency of updates to the regex crate if you are interested: https://crates.io/crates/regex/versions https://crates.io/crates/regex/versions. Sometimes a release in a few days, or a few a month. > Or how about the random number generator crate? Even more interesting, because `rand` hasn't even reached 1.0 yet! https://crates.io/crates/rand/versions https://crates.io/crates/rand/versions Specifically, the authors are still deciding the right way to architect the library for the myriad of uses that Rust has. > or even completely vanish (left-pad) In 99.99% of the cases, you cannot remove a crate from crates.io; you can only prevent new projects from adding the crate as a dependency. The other 0.01% is because of legal reasons, and there's not much to be done about that. > For every crate you add, you need to do a licence audit https://github.com/onur/cargo-license https://github.com/onur/cargo-license claims to show you the licenses of every dependency. It's required to have a license to publish to crates.io.

shepmaster 8y ago

> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust. More importantly, due to Rust's backwards compatibility guarantees, you can never remove something once it has been added. I vaguely wave towards Python's 3-5 built-in "get data from a URL" libraries as an example of a bad route that this can take. The regex crate can release a backwards-incompatible version 2 without destroying the entire ecosystem since multiple versions of a crate can co-exist in the final graph of dependencies.