Hacker News Reader

Comment by rastignack | Hacker News Reader

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!)

View on HN

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.

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

For crypto, isn't assembly used to help prevent timing attacks? I don't know if that can be done in pure Rust.

At least let’s get rid of c and put this in stdlib, shall we ?

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

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

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

Rust had a small standard library and that’s ok (https://blog.nindalf.com/posts/rust-stdlib/)

Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.

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.

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

Reply on news.ycombinator.com