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.

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.

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.

* 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.

https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.

According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different licenses, with zero obvious guarantees.

https://crates.io/crates/regex

(Regex moved out of the nursery a while back)

The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up with something better".

The guarantees aren't advertised, they're known. We can do a better job of advertising this, some of the work this year is related to that.

I'm sure the Rust team knows and trusts these (or they even are Rust team members), but how should outsiders know this?

Researching trustworthiness of individual authors, getting approval for different licenses, tracking and updating required notices in documentation etc. for every single dependency transitively(!) seriously takes a lot of effort. Updating dependencies that switch sub-(sub-...)-dependencies freely can turn from a simple cargo command into a month of work. A big standard library (or an equivalent construct) can really save the day there.

> The guarantees aren't advertised, they're known.

It is known. -- Jhiqui

Glad to hear improving this is in the works anyway.

That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)

I think it would be important to include in this pledge:

* Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.)

* Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.)

* Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.)

Or maybe this already exists and I'm just uninformed?

For context, I'm a Python programmer by day and well used to the comforts of its expansive standard library. From that perspective, splitting your stdlib into a first-class and a second-class stdlib seems weird, and I'm trying to make sense of it.

There's no inherent reason to put them in the stdlib aside from "other languages do it".

And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up people can switch to that; without being tied to the language version. These libraries will still be maintained, but may no longer be the recommended way to do things. Being outside the stdlib gives some liquidity to the crate.

This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least for a few years). I'm not trying to learn yet another CADT language / ecosystem.

Also note that both crates mentioned in this subthread (regex and rand) are at version 0.x; to a not-really-a-rust-person like me, it signals "experimental API, avoid avoid avoid". I assume that is the reason to start a concerted effort to get everything to 1.0 levels.

(I'm mostly commenting because the roadmap under discussion seems to be heading towards the sort of promised stability that I want to see; so having somebody known to be rather close to rust development saying the exact opposite rather unsettles me. Sorry.)

> It means any code that uses the old (inferior) urllib continues to work,

Rust lets you have multiple versions of a transitive dependency in your project, so they would continue to work.

Rand is a vocabulary crate (traits Rng and Rand are used for inter-crate exchange), so it's very sensitive to version coupling.

"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?

    fn random<R: std::rand::Random>(r: R)

I also might be missing something.

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.