11 ms·

Don't change the language to make it easier (unless that can be a free lunch), but get someone doing a "Today in rust" or "Doing X in rust" blog/vlog. Also plea

Don't change the language to make it easier (unless that can be a free lunch), but get someone doing a "Today in rust" or "Doing X in rust" blog/vlog. Also please get some sort of RNG into the main language (not as a crate).

bryanlarsen 10y ago
https://this-week-in-rust.org/ https://this-week-in-rust.org/
steveklabnik 10y ago
What advantage would putting an RNG into the language do? Are there any languages where an RNG is a language construct?
- Manishearth 10y ago
  I think they mean stdlib. RNG is not in the language for any language I can think of.
  - Animats 10y ago
    It's in BASIC, as RND(). The usual Basic RNG is good enough for games, but not good enough for crypto.
  - davidtgoldblatt 10y ago
    It's part of the core language semantics (arguably the core language semantics) for Java2K (http://p-nand-q.com/programming/languages/java2k/ http://p-nand-q.com/programming/languages/java2k/).
- kzrdude 10y ago
  Relieve crates of version coupling stress. I effectively can't release an 1.0 crate if I have rand as a public dependency; if it has a new major version, I need to have that too to keep in sync and do versioning right. Rand is a vocabulary crate (traits Rng and Rand are used for inter-crate exchange), so it's very sensitive to version coupling.
  - steveklabnik 10y ago
    Interesting, thanks. That does seem valuable; I'm not sure that rand is gonna shoot for a 2.0 any time soon after its 1.0, but that is something being in-tree would prevent. "vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.
    - akiselev 10y ago
      > "vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside. How would this interact with the orphan rule? Wouldnt this mean the vocabulary traits would not have default or std library type implementations and would have to be wrapped in newtypes, defeating the purpose of having them for inter-crate exchange? I guess you could wire types explicitly with Into/From in user code. Are there any traits unimplemented in std now that these vocab traits would look like?
      - steveklabnik 10y ago
        It helps with the orphan rule, as everyone would be importing the trait from std. From/Into are the same kind of traits. That is, the idea is that the rand crate would implement std::rand::Random, and so would some rand2 crate, and then I could write my own crate saying fn random<R: std::rand::Random>(r: R) and it would work with either one. No need for newtypes. I also might be missing something.
    - epage 10y ago
      stdlib or in a crate for just the trait similar to log?
      - steveklabnik 10y ago
        The parent is worried about 2.0, so that would imply in stdlib. No reason it couldn't be done as a crate just for the trait as well, but that at least leaves the possibility of a 2.0 open.
Manishearth 10y ago
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
GolDDranks 10y ago
The Rust's goals of high performance, safety and pay-what-your-use and you-couldn't-hand-code-better won't be sacrificed for sure. The point in ergonomics improvements is to identify "free lunches" that aren't yet taken advantage of. That being said, lifetimes and traits being both complex and unfamiliar features, there's always going to be quite of a learning curve. But one can always reduce the amount of papercuts. If nothing else, one can at least make the documentation better, the ecosystem libraries better and error messages even smarter.
- junk_disposal 10y ago
  Can you say that traits are like Go interfaces?
  - steveklabnik 10y ago
    Yes and no; I've always really enjoyed http://softwareengineering.stackexchange.com/questions/247298/how-are-rust-traits-different-from-go-interfaces http://softwareengineering.stackexchange.com/questions/24729... as a comparison between the two. It's old enough that it's before Rust 1.0, so some of the syntax is a _teeny_ bit wrong (int isn't a type any more, you'd use isize) but the macro picture is the same.

bryanlarsen 10y ago

https://this-week-in-rust.org/ https://this-week-in-rust.org/

steveklabnik 10y ago

What advantage would putting an RNG into the language do? Are there any languages where an RNG is a language construct?

Manishearth 10y ago
I think they mean stdlib. RNG is not in the language for any language I can think of.
- Animats 10y ago
  It's in BASIC, as RND(). The usual Basic RNG is good enough for games, but not good enough for crypto.
- davidtgoldblatt 10y ago
  It's part of the core language semantics (arguably the core language semantics) for Java2K (http://p-nand-q.com/programming/languages/java2k/ http://p-nand-q.com/programming/languages/java2k/).
kzrdude 10y ago
Relieve crates of version coupling stress. I effectively can't release an 1.0 crate if I have rand as a public dependency; if it has a new major version, I need to have that too to keep in sync and do versioning right. Rand is a vocabulary crate (traits Rng and Rand are used for inter-crate exchange), so it's very sensitive to version coupling.
- steveklabnik 10y ago
  Interesting, thanks. That does seem valuable; I'm not sure that rand is gonna shoot for a 2.0 any time soon after its 1.0, but that is something being in-tree would prevent. "vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.
  - akiselev 10y ago
    > "vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside. How would this interact with the orphan rule? Wouldnt this mean the vocabulary traits would not have default or std library type implementations and would have to be wrapped in newtypes, defeating the purpose of having them for inter-crate exchange? I guess you could wire types explicitly with Into/From in user code. Are there any traits unimplemented in std now that these vocab traits would look like?
    - steveklabnik 10y ago
      It helps with the orphan rule, as everyone would be importing the trait from std. From/Into are the same kind of traits. That is, the idea is that the rand crate would implement std::rand::Random, and so would some rand2 crate, and then I could write my own crate saying fn random<R: std::rand::Random>(r: R) and it would work with either one. No need for newtypes. I also might be missing something.
  - epage 10y ago
    stdlib or in a crate for just the trait similar to log?
    - steveklabnik 10y ago
      The parent is worried about 2.0, so that would imply in stdlib. No reason it couldn't be done as a crate just for the trait as well, but that at least leaves the possibility of a 2.0 open.

Manishearth 10y ago

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

GolDDranks 10y ago

The Rust's goals of high performance, safety and pay-what-your-use and you-couldn't-hand-code-better won't be sacrificed for sure. The point in ergonomics improvements is to identify "free lunches" that aren't yet taken advantage of. That being said, lifetimes and traits being both complex and unfamiliar features, there's always going to be quite of a learning curve. But one can always reduce the amount of papercuts. If nothing else, one can at least make the documentation better, the ecosystem libraries better and error messages even smarter.

junk_disposal 10y ago
Can you say that traits are like Go interfaces?
- steveklabnik 10y ago
  Yes and no; I've always really enjoyed http://softwareengineering.stackexchange.com/questions/247298/how-are-rust-traits-different-from-go-interfaces http://softwareengineering.stackexchange.com/questions/24729... as a comparison between the two. It's old enough that it's before Rust 1.0, so some of the syntax is a _teeny_ bit wrong (int isn't a type any more, you'd use isize) but the macro picture is the same.