Stewardship and future of the rand lib in the nursery

[bstrie]

Now that Huon has crossed Apple's event horizon, I would like to ask the libs team to reevaluate the future of the rust-lang-nursery/rand crate. In particular I'm referring to a long-ago comment from Huon that he was working on an overhaul of the rand lib, which has somewhat served to stall outside progress on the lib.

I bring this up now because an old colleague of mine, @bhickey (who has already submitted several PRs to rand, e.g. rust-random/rand#113 ), has expressed interest in taking stewardship of the rand crate, but our enthusiasm is dampened by rand's limbo-ness. Specifically it's uncertain whether someone on the libs team has already decided to take stewardship of the rand crate, or whether there is a consensus on whether the current rand crate ought to be moved to rust-lang-deprecated pending a total overhaul of the API (as some people seemed to almost imply last year).

If the libs team is receptive, I'm sure bhickey would be happy to discuss potential changes to the API with any interested parties. And if someone on the libs team has already decided to tackle this themselves, I can vouch that bhickey is about as close to an expert on random number generation as we are likely to find, and could provide valuable consultation on any future redesign.

(As to the question of why not just work on an external rand crate for now, well, yes, that is what we intend to do, but IMO prospects for large-scale adoption are bleak when it comes to competing with pseudo-blessed libs (e.g. how much effort we continue to put into evangelizing Serde, which still seems to see less real-world use than rustc-serialize).)

[bstrie]

Related to #27703.

[nagisa]

I’m pretty sure there was a proposal from Huon somewhere (found it). Involving streams and ranges. I remember the proposal being pretty good, we could build on it.

As for stewardship, somebody has to take the steering wheel of the crate at some point. On the other hand, I’m not against the idea of somebody coming forward with their take on the random crate and letting the download numbers to decide.

[alexcrichton]

@BurntSushi also wrote up a summary on internals

[bhickey]

As @bstrie mentioned, I'm interested in seeing rand develop further. Huon's proposal looks like a very strong starting point. Apart from API updates, a few changes I'd like to see are a split between PRNGs and CSPRNGs, better underlying generators, and more distributions and algorithms (ex. weighted random shuffle).

Regardless of the direction we go in, the crate could really use someone in a position to merge or reject PRs at the very least.

[alexcrichton]

The libs team got a chance to talk about this during the triage meeting today and the conclusions were:

• Currently the rand crate is in "wait for a comprehensive design mode." In that sense we'll still merge bugfixes, but new features and/or changing functionality we're holding off on at this time.
• We're more than willing to experiment here, but this is a pretty important crate that's semi-defacto stable here, so we'd want a comprehensive design before merging new PRs.
• @bhickey if you'd like, we'd love to see experimentation in crates here! Perhaps you'd like to poke around and then afterwards make a proposal?

[Mark-Simulacrum]

I'm going to go ahead and close. The rand crate needs help; but there is no need for this specific issue since it tracks no problems and has no solutions, @rust-lang/libs might want to ping @bhickey and/or @bstrie to discuss the future of random numbers in Rust since we have an ongoing Libz Blitz.