5 ms·

Any particular reason rng must be in the stdlib? It's an "official" crate, maintained by the Rust developers. In general Rust tries to keep things out of its st

Any particular reason rng must be in the stdlib? It's an "official" crate, maintained by the Rust developers. In general Rust tries to keep things out of its stdlib instead opting for crates. It lets these evolve independently of the stdlib (not tied to rustc releases), and also lets them have their own versioning (none of that urllib2 urllib3 nonsense)

XorNot 10y ago
I would say random numbers are a fairly core programming construct for a standard library. They're important, difficult to get right, and have huge implications if you get them wrong.
- wyldfire 10y ago
  But given how easy/simple/common it is to depend on a crate, what practical problem would it solve for it to be in libstd? Maybe it's difficult for the community to identify the anointed RNG?
- Manishearth 10y ago
  This doesn't answer my question, though. Most of the "fairly core programming constructs" are not in the stdlib for Rust (like regexes) The Rust stdlib is mostly core abstractions and platform-dependent stuff. Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.
  - sevensor 10y ago
    In that case, it sounds like "officially blessed crates" are a second-level stdlib with weaker guarantees about availability across time and across platforms. I'm fine with that idea, but from my outside perspective this is a confused message. Better to call the blessed crates "stdlib extensions" or something like that.
    - Manishearth 10y ago
      Why "weaker guarantees across platforms"? These crates have the same guarantees about platform support. Availability across time is also similar, really.
      - 1wd 10y ago
        In most other programming languages functions in the standard library: * Are guaranteed to work correctly on all platforms where the language works. * Will always work with the latest stable release of the language. * Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.) * Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.) * Are under no danger of being abandoned simply due to lost interest of the author. * Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!) And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation. If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.
        Manishearth 10y ago
        Most of these are true for rand. It's in the nursery so it might (probably not though) be deprecated in favor of a different library, but it would continue to work because Rust is backwards compatible. https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.
        10y ago
  - iopq 10y ago
    You can't use rand in play.rust-lang.org so it's hard to get help from IRC since they can't get your error messages easily and fix them.
- vertex-four 10y ago
  So's encryption, possibly moreso, and yet that probably shouldn't be in the standard library.
sevensor 10y ago
It's a battery people are pretty well used to seeing included in a language. POSIX even mandates one for C. For repeatable simulation work you might want something more robust, and hopefully everybody knows it's no use for crypto, but it's a handy thing to have around if you need to flip a digital coin.
- Manishearth 10y ago
  It's not harder to use in Rust than it is to pull in a C header file, though.

XorNot 10y ago

I would say random numbers are a fairly core programming construct for a standard library. They're important, difficult to get right, and have huge implications if you get them wrong.

wyldfire 10y ago
But given how easy/simple/common it is to depend on a crate, what practical problem would it solve for it to be in libstd? Maybe it's difficult for the community to identify the anointed RNG?
Manishearth 10y ago
This doesn't answer my question, though. Most of the "fairly core programming constructs" are not in the stdlib for Rust (like regexes) The Rust stdlib is mostly core abstractions and platform-dependent stuff. Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.
- sevensor 10y ago
  In that case, it sounds like "officially blessed crates" are a second-level stdlib with weaker guarantees about availability across time and across platforms. I'm fine with that idea, but from my outside perspective this is a confused message. Better to call the blessed crates "stdlib extensions" or something like that.
  - Manishearth 10y ago
    Why "weaker guarantees across platforms"? These crates have the same guarantees about platform support. Availability across time is also similar, really.
    - 1wd 10y ago
      In most other programming languages functions in the standard library: * Are guaranteed to work correctly on all platforms where the language works. * Will always work with the latest stable release of the language. * Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.) * Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.) * Are under no danger of being abandoned simply due to lost interest of the author. * Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!) And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation. If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.
      - Manishearth 10y ago
        Most of these are true for rand. It's in the nursery so it might (probably not though) be deprecated in favor of a different library, but it would continue to work because Rust is backwards compatible. https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.
        10y ago
- iopq 10y ago
  You can't use rand in play.rust-lang.org so it's hard to get help from IRC since they can't get your error messages easily and fix them.
vertex-four 10y ago
So's encryption, possibly moreso, and yet that probably shouldn't be in the standard library.

sevensor 10y ago

It's a battery people are pretty well used to seeing included in a language. POSIX even mandates one for C. For repeatable simulation work you might want something more robust, and hopefully everybody knows it's no use for crypto, but it's a handy thing to have around if you need to flip a digital coin.

Manishearth 10y ago
It's not harder to use in Rust than it is to pull in a C header file, though.