News for hackers. Stuff that matters.
Re:Rust's 2017 Roadmap by steveklabnik on Monday February 06, 2017 @03:39PM (#13583645)
What advantage would putting an RNG into the language do? Are there any languages where an RNG is a language construct?
Re:Rust's 2017 Roadmap by kzrdude on Monday February 06, 2017 @04:11PM (#13584005)
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.

Re:Rust's 2017 Roadmap by steveklabnik on Monday February 06, 2017 @04:22PM (#13584153)
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.

Re:Rust's 2017 Roadmap by akiselev on Monday February 06, 2017 @05:47PM (#13585051)
> "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?

Re:Rust's 2017 Roadmap by steveklabnik on Monday February 06, 2017 @06:33PM (#13585388)
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.

Re:Rust's 2017 Roadmap by epage on Monday February 06, 2017 @06:12PM (#13585233)
stdlib or in a crate for just the trait similar to log?
Re:Rust's 2017 Roadmap by steveklabnik on Monday February 06, 2017 @06:28PM (#13585353)
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.
Re:Rust's 2017 Roadmap by kzrdude on Monday February 06, 2017 @09:04PM (#13586326)
Not worried about 2.0.

Rand is at version 0.3 and stagnating. I'm worried about 0.3, 0.4, 0.5. Those that have rand as a public dependency cannot release 1.0 now, if they do, they need to release 2.0 when rand goes to 0.4 and so on.

Re:Rust's 2017 Roadmap by Manishearth on Monday February 06, 2017 @03:43PM (#13583678)
I think they mean stdlib. RNG is not in the language for any language I can think of.
Re:Rust's 2017 Roadmap by Animats on Monday February 06, 2017 @04:05PM (#13583932)
It's in BASIC, as RND(). The usual Basic RNG is good enough for games, but not good enough for crypto.
Re:Rust's 2017 Roadmap by davidtgoldblatt on Monday February 06, 2017 @04:12PM (#13584016)
It's part of the core language semantics (arguably the core language semantics) for Java2K (http://p-nand-q.com/programming/languages/java2k/).