4 ms·

I've been using Kattis problems as a way to work on my Rust skills. The problem there is you're limited to the standard library. Rust's ultra-minimal stdlib m

I've been using Kattis problems as a way to work on my Rust skills. The problem there is you're limited to the standard library. Rust's ultra-minimal stdlib makes a number of those kattis problems remarkably hard to implement, where I've managed to whip up something in short order in Python using the stdlib. I keep thinking that Rust has gone a little too far on the "keep it minimal" front. It also really disturbs me just how often with rust I'm having to rely on third party hosted crates. That's one huge amount of trust going on there.

steveklabnik 8y ago
Part of what we do to balance this out is to have the team make some of those third party packages; the regex crate is a good example of that. It’s still maintained by the team even if it’s not in the standard library itself.
- TotempaaltJ 8y ago
  So then why isn't the regex lib part of the standard library?
  - richardwhiuk 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. 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.
  - s9df8 8y ago
    Your concern may be founded in the difficulty other languages' package managers present. With regard to C/++, there really isn't package management at all, making package inclusion a big decision. With regard to Ruby (for example), the package management is actually pretty unreliable and terrible given how many gems require system libraries and incompatibilities of gems across Ruby versions. With Rust, the package manager is very good. So it's not a problem in practice.

steveklabnik 8y ago

Part of what we do to balance this out is to have the team make some of those third party packages; the regex crate is a good example of that. It’s still maintained by the team even if it’s not in the standard library itself.

TotempaaltJ 8y ago
So then why isn't the regex lib part of the standard library?
- richardwhiuk 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. 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.
- s9df8 8y ago
  Your concern may be founded in the difficulty other languages' package managers present. With regard to C/++, there really isn't package management at all, making package inclusion a big decision. With regard to Ruby (for example), the package management is actually pretty unreliable and terrible given how many gems require system libraries and incompatibilities of gems across Ruby versions. With Rust, the package manager is very good. So it's not a problem in practice.