Compared to C/C++, I’d say the Rust standard library is very feature full. Regarding crates, they are super easy to pull in compared with random C/C++ libraries, and the crates generally are fairly high quality.
Tokio provides a bit more features, but is a damn huge runtime to depend on, and is creating fragmentation.
I feel rust needs to be taken out of the hands of former c++ devs / language theorists and put straight under responsibility of library design experts (rip off go’s stdlib for gods sake!)
Crypto isn’t a core competency for the standard library authors and this it’s better to offload that responsibility. Maybe once a library becomes de facto in the community (ring?) then it might make more sense.
The other reason to prefer a smaller standard library is that it can often be difficult to strip away the unused bits from the resultant binary. Rust statically links which hopefully fixes most of this, but I suspect possibly not all.
I agree they need to standardize an effect system and unify async so that there’s a way to plug in arbitrary runtimes.
Ring is mostly C/Assembly. Good bye safety ! Offloading core security routines is such a bad design.
> The other reason to prefer a smaller standard library is that it can often be difficult to strip away the unused bits from the resultant binary.
It’s actually already handled quite well, and could also be behind feature flags.
Really, a standard library with feature flags and editions would make rust ridiculously much more productive… such a waste.
Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time.
But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable
> No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality.
As a bonus, rustls is under active development with sponsorship from Google, AWS and fly.io, with the aim of making a high quality, memory-safe TLS stack - https://www.memorysafety.org/initiative/rustls/
You said
> a standard library with feature flags and editions would make rust ridiculously much more productive
What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate?
I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.
If you are all alone developing and can audit the crate properly, sure.
However when there’s a team, whose favorite lib should we pick ? How many of them shall we audit ? What’s their license ? How’s code attribution managed ? Etc etc
Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.
I'd like to see an "extension" library managed like the standard library (and shipped with Rust, included in the prelude, etc) but with SemVer, so that breaking changes could be made more easily.
You aren't forced to use the more obscure methods in std. You can almost always recreate them with simple code and suffer no real performance or readability hits.
Former c++ devs are smart people. I work with some, and value their input specifically when designing libraries...