7 ms·

In my post, I specifically call on proc-macro support (syn and quote) plus rand (not all of rand though, just the "give me a random number" functionality that c

In my post, I specifically call on proc-macro support (syn and quote) plus rand (not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity) to be added to the Rust standard library. But I feel these are particularly justified because they're already present, just not accessible. Overall, I think Rust's "batteries not included" approach is a good tradeoff.

orf 7y ago
> not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity Are you suggesting including the core `rand` crate with some traits and a basic pseudo-random generator in the stdlib, and allowing other crates to use those traits to implement the many other[1] RNGs? I'm honestly not sure this is a good idea, it seems the rand crate has undergone a few iterations, crystalizing this inside the stdlib might lead to problems? 1. https://rust-random.github.io/book/guide-rngs.html https://rust-random.github.io/book/guide-rngs.html
- raphlinus 7y ago
  I admit, design of a proper random number library API is tricky, and experience from deploying rand will no doubt be invaluable. The point I was trying to make is that some use cases require sophistication such as being able to choose different algorithms, but a lot of the times rand shows up in a build time histogram, it's just because the user wanted some pretty good random numbers; a much simpler API would suffice.
  - anp 7y ago
    I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.
    - Dylan16807 7y ago
      Having a very simple API is not at odds with security, though. A simple API could automatically seed from the OS and then run a tiny loop with sha2 or sha3, for example.
      - vunie 7y ago
        SHA2 is not designed to be used as a RNG. SHA3 might be a little bit better with its "streaming" modes, but there are many far better and faster ways to get random bits.
        Dylan16807 7y ago
        It doesn't have to be the absolute fastest, it just has to work. What is far better and faster than SHA3? And while SHA2 wasn't designed for that use, it's easy to make simple and provably correct constructs that turn a secure hash into a secure RNG.
        heavenlyblue 7y ago
        You’re speculating to prove a point. I would definitely not want my std to be designed this way.
        Dylan16807 7y ago
        1. It was just an example. 2. You definitely don't want your std to be designed with a simple API to a fast, secure, and popular crypto primitive? Pretend I named your favorite one, to avoid bikeshedding issues.
        edflsafoiewq 7y ago
        ChaCha20 is widely used for CSRNG.
        Dylan16807 7y ago
- ChrisSD 7y ago
  I would like getrandom[0] to be in the standard library. It simply abstracts over the platform random and is even used by the standard library itself. [0]: https://crates.io/crates/getrandom https://crates.io/crates/getrandom
est31 7y ago
Inclusion of parts of rand might be a good idea, but syn seems to need breaking changes as for long as the Rust language is getting new features: > Be aware that the underlying Rust language will continue to evolve. Syn is able to accommodate most kinds of Rust grammar changes via the nonexhaustive enums and Verbatim variants in the syntax tree, but we will plan to put out new major versions on a 12 to 24 month cadence to incorporate ongoing language changes as needed. https://github.com/dtolnay/syn/releases/tag/1.0.0 https://github.com/dtolnay/syn/releases/tag/1.0.0
- raphlinus 7y ago
  Since stdlib and compiler releases are tightly coordinated, that shouldn't be a problem, no?
  - anp 7y ago
    How do you accommodate breaking changes to the public interface of std?
    - raphlinus 7y ago
      Right, I see your point here. There are non-trivial issues that need to be worked out, which I'm sure is one reason it's not in the library yet. Another (mentioned elsewhere) is that it takes time to converge on what a good API might look like.
      - heavenlyblue 7y ago
        Well, with non-std I can always downgrade or upgrade the library. With std I am bounded by the current language version.
        snovv_crash 7y ago
        You can only down or upgrade if uour dependencies don't depend on it too. Having a defacto standard library has more issues IMO than a real standard library.
burntsushi 7y ago
I don't necessarily disagree. I have my own pet things that I'd like to see in std too. I've long wanted to see lazy_static in std. Funnily enough, it looks like `once_cell` might wind up being a nicer approach to achieving a similar end, but without using a macro. So if we had added it to std many years ago, we might find ourselves with an API that we regret! It's tough. With that said, if `syn` finds itself in a spot where it needs to do a breaking change release for a new language feature, then that would be tricky. It sounds like syn's architecture is pretty flexible (non-exhaustive enums), but it's not clear to me that it could support all possible language additions without breaking changes.
- galangalalgol 7y ago
  I think I get the tradeoffs but while my company would be a perfect fit for rust, we do all our development on an airgapped network. Custom registries are a thing now, but picking and choosing which packages our IT will consider trustworthy and then taking the subset of that with a license our legal will approve an then prunimg things with dpendencies that are now missing is a huge task that needs to happen at regular intervals and probably leaves some pretty big gaps in functionality. Its a shame, I like the language.
  - burntsushi 7y ago
    At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.
    - mmastrac 7y ago
      > Virtually everything in the Rust ecosystem is permissively licensed. I just did our license audit and 100% of our shipped deps were Apache | MIT. If you can clear those two licenses with legal, you should be good to go for virtually any crate. Might be worth releasing my one liner for this if anyone else finds it useful.

orf 7y ago

> not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity Are you suggesting including the core `rand` crate with some traits and a basic pseudo-random generator in the stdlib, and allowing other crates to use those traits to implement the many other[1] RNGs? I'm honestly not sure this is a good idea, it seems the rand crate has undergone a few iterations, crystalizing this inside the stdlib might lead to problems? 1. https://rust-random.github.io/book/guide-rngs.html https://rust-random.github.io/book/guide-rngs.html

raphlinus 7y ago
I admit, design of a proper random number library API is tricky, and experience from deploying rand will no doubt be invaluable. The point I was trying to make is that some use cases require sophistication such as being able to choose different algorithms, but a lot of the times rand shows up in a build time histogram, it's just because the user wanted some pretty good random numbers; a much simpler API would suffice.
- anp 7y ago
  I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.
  - Dylan16807 7y ago
    Having a very simple API is not at odds with security, though. A simple API could automatically seed from the OS and then run a tiny loop with sha2 or sha3, for example.
    - vunie 7y ago
      SHA2 is not designed to be used as a RNG. SHA3 might be a little bit better with its "streaming" modes, but there are many far better and faster ways to get random bits.
      - Dylan16807 7y ago
        It doesn't have to be the absolute fastest, it just has to work. What is far better and faster than SHA3? And while SHA2 wasn't designed for that use, it's easy to make simple and provably correct constructs that turn a secure hash into a secure RNG.
        heavenlyblue 7y ago
        You’re speculating to prove a point. I would definitely not want my std to be designed this way.
        Dylan16807 7y ago
        1. It was just an example. 2. You definitely don't want your std to be designed with a simple API to a fast, secure, and popular crypto primitive? Pretend I named your favorite one, to avoid bikeshedding issues.
        edflsafoiewq 7y ago
        ChaCha20 is widely used for CSRNG.
        Dylan16807 7y ago
ChrisSD 7y ago
I would like getrandom[0] to be in the standard library. It simply abstracts over the platform random and is even used by the standard library itself. [0]: https://crates.io/crates/getrandom https://crates.io/crates/getrandom

est31 7y ago

Inclusion of parts of rand might be a good idea, but syn seems to need breaking changes as for long as the Rust language is getting new features: > Be aware that the underlying Rust language will continue to evolve. Syn is able to accommodate most kinds of Rust grammar changes via the nonexhaustive enums and Verbatim variants in the syntax tree, but we will plan to put out new major versions on a 12 to 24 month cadence to incorporate ongoing language changes as needed. https://github.com/dtolnay/syn/releases/tag/1.0.0 https://github.com/dtolnay/syn/releases/tag/1.0.0

raphlinus 7y ago
Since stdlib and compiler releases are tightly coordinated, that shouldn't be a problem, no?
- anp 7y ago
  How do you accommodate breaking changes to the public interface of std?
  - raphlinus 7y ago
    Right, I see your point here. There are non-trivial issues that need to be worked out, which I'm sure is one reason it's not in the library yet. Another (mentioned elsewhere) is that it takes time to converge on what a good API might look like.
    - heavenlyblue 7y ago
      Well, with non-std I can always downgrade or upgrade the library. With std I am bounded by the current language version.
      - snovv_crash 7y ago
        You can only down or upgrade if uour dependencies don't depend on it too. Having a defacto standard library has more issues IMO than a real standard library.

burntsushi 7y ago

I don't necessarily disagree. I have my own pet things that I'd like to see in std too. I've long wanted to see lazy_static in std. Funnily enough, it looks like `once_cell` might wind up being a nicer approach to achieving a similar end, but without using a macro. So if we had added it to std many years ago, we might find ourselves with an API that we regret! It's tough. With that said, if `syn` finds itself in a spot where it needs to do a breaking change release for a new language feature, then that would be tricky. It sounds like syn's architecture is pretty flexible (non-exhaustive enums), but it's not clear to me that it could support all possible language additions without breaking changes.

galangalalgol 7y ago
I think I get the tradeoffs but while my company would be a perfect fit for rust, we do all our development on an airgapped network. Custom registries are a thing now, but picking and choosing which packages our IT will consider trustworthy and then taking the subset of that with a license our legal will approve an then prunimg things with dpendencies that are now missing is a huge task that needs to happen at regular intervals and probably leaves some pretty big gaps in functionality. Its a shame, I like the language.
- burntsushi 7y ago
  At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.
  - mmastrac 7y ago
    > Virtually everything in the Rust ecosystem is permissively licensed. I just did our license audit and 100% of our shipped deps were Apache | MIT. If you can clear those two licenses with legal, you should be good to go for virtually any crate. Might be worth releasing my one liner for this if anyone else finds it useful.