[JoshTriplett]

> Generate a random number.

Working on adding that to the standard library, along with a handful of other "you should be able to do this without a dependency" things. We're being very cautious to not fall into the trap of "the standard library is where code goes to die", which is the problem some languages' standard libraries have had. But there are more things we should add, nonetheless.

[throwaway17_17]

From the outside looking in, it seems that despite trends in language development to the contrary, Rust has taken an extremely conservative stance on the inclusions into and the evolution of its standard library. I applaud the decision and the will of the core teams for sticking to their guns in this area. I had assumed that the reasons you give above were the motivating factors for being vigilant about the slower cadence of development and smaller ‘size’ of additions/alterations/removals to the standard library . But having it confirmed makes it very comfortable for me to think it is a nearly unqualified positive stance for the language to take.

I have seen your talk about the long future of Rust and I think there is the implication that you and the other Rust language developers are looking toward a 25-30 year timeframe (which encompasses nearly every language in wide spread use today) as the minimum expected lifespan of the language, with a view to be responsive and flexible enough to see the language continue to adapt and evolve throughout a longer period as well. With that type of longevity as an active consideration in planning the language’s growth/evolution I think Rust is setting a good precedent for non-BDFL style governance and stewardship of programming languages. I would hope a more long term compatible view takes hold in programming language development particularly, but general software development could probably stand to benefit if the time horizon was lengthened well beyond what seems to be standard today.

[JoshTriplett]

Thank you very much; all of that is very gratifying to hear.

And yes, being conservative about what we add to the standard library is a very deliberate decision. We also try not to do novel design in the standard library; design and iteration should happen in the ecosystem.

There are also some things that we're unlikely to ever add, such as cryptographic algorithms, precisely because we wouldn't be confident that we could fix issues with them without breaking compatibility. Crates in the ecosystem get to have a 2.0; the standard library doesn't. (Editions give us some ability to evolve the standard library, but the standard library still has to support every past edition.)

Also: I wish this level of discourse were what we could have with everyone who expresses a dislike of Rust. This has been an entirely pleasant experience, and I appreciate your feedback. Even if Rust isn't your particular cup of tea and you'd prefer to write your own code in something else, I'm gratified to know that things like this make it more tolerable. We often have to deal with code in languages that aren't our first choice.