4 ms·

I would say that having methods like ‘and_then_if_finally()’ or ‘then_unwrap_or_none_and_map()’ (I’m barely exaggerating) is less of a feature than say, json pa

I would say that having methods like ‘and_then_if_finally()’ or ‘then_unwrap_or_none_and_map()’ (I’m barely exaggerating) is less of a feature than say, json parsing and hashing / crypto, which are sorely missing. 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!)

cookieperson 3y ago
Go and rust are not the same thing. Go is fine for what it is if you agree with it's opinions. But a lot of people are reaching for rust for different reasons then someone would reach for go. It makes sense that their std libs are different... Especially knowing the differences in the languages themself. 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...
vlovich123 3y ago
JSON is handled well enough by serde which is extremely popular. Rust also has various string manipulation utilities and an insanely fast and high quality regexp implementation. 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.
- SAI_Peregrinus 3y ago
  Crypto MUST NOT become part of the Rust standard library, because Rust's compatibility guarantees would have to be broken when any underlying cryptographic primitive or protocol is broken (or worryingly weakened) and needs to be removed. While that could be done with the "unsoundness fix" escape hatch, it's better to minimize such changes. 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.
- rastignack 3y ago
  > Crypto isn’t a core competency for the standard library authors and this it’s better to offload that responsibility. 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.
  - GreedCtrl 3y ago
    For crypto, isn't assembly used to help prevent timing attacks? I don't know if that can be done in pure Rust.
    - rastignack 3y ago
      At least let’s get rid of c and put this in stdlib, shall we ?
  - nindalf 3y ago
    > Ring is mostly C/Assembly 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-report.pdf 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/ 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.

cookieperson 3y ago

Go and rust are not the same thing. Go is fine for what it is if you agree with it's opinions. But a lot of people are reaching for rust for different reasons then someone would reach for go. It makes sense that their std libs are different... Especially knowing the differences in the languages themself. 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...

vlovich123 3y ago

JSON is handled well enough by serde which is extremely popular. Rust also has various string manipulation utilities and an insanely fast and high quality regexp implementation. 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.

SAI_Peregrinus 3y ago
Crypto MUST NOT become part of the Rust standard library, because Rust's compatibility guarantees would have to be broken when any underlying cryptographic primitive or protocol is broken (or worryingly weakened) and needs to be removed. While that could be done with the "unsoundness fix" escape hatch, it's better to minimize such changes. 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.
rastignack 3y ago
> Crypto isn’t a core competency for the standard library authors and this it’s better to offload that responsibility. 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.
- GreedCtrl 3y ago
  For crypto, isn't assembly used to help prevent timing attacks? I don't know if that can be done in pure Rust.
  - rastignack 3y ago
    At least let’s get rid of c and put this in stdlib, shall we ?
- nindalf 3y ago
  > Ring is mostly C/Assembly 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-report.pdf 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/ 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.