Subtopic on std-lib thick vs thin

Continuing the discussion from (spectacular) failure of abstraction, compile times, and toolboxes vs thin stdlib:

A quote from the second linked post:

Branch to Stream API and types on implementation details mentioned in the following post.

Read below post with regard to hex encoding and macros in stdlib; else branch to Does Rust have severe shortcomings.

This discussion revolves around whether the Rust standard library should contain more features. Central arguments of @peter_bertok are:

Yes. UUIDs are not required for many useful Rust application. Ripgrep is one of them. We should celebrate that the language’s designers have been modest and didn’t err on the side of putting too much in the standard library.

1 Like
  • Numbers types are most definitely in the standard library. But I’m happy to discuss more specific proposals for things to go in the standard library.
  • I don’t think there is a single right way to do bitfields; depending on your use case you may want a different low-level implementation. I don’t think we should put this in the stdlib.
  • UUIDs: I’m happy for this to go in the stdlib on the condition that randomness is also in the stdlib.
  • Randomness: This should probably stay out of the standard library. Many interesting platforms that Rust targets (even without no_std) don’t have infrastructure for generating cryptographically secure random numbers. But perhaps we should standardise just the Rand and Rng traits from the rand crate. If std won’t contain a cryptographically secure prng then it really also shouldn’t contain a weak prng; it just sets people up to do the wrong thing.
  • Temp directory: I’m not convinced there’s a single canonical way to do this on all platforms, so probably not in std?
  • Time: chrono seems to be really strong. Perhaps it should be put in std.
  • Urls: I’m ambivalent.
1 Like

@peter_bertok :wave: