Hacker News Reader

Comment by saghm | Hacker News Reader

The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be external crates, versions bumps can happen independently happen, which means (among other things) that major version bumps are possible.

View on HN

That's certainly an advantage. But for devs like me, we are used to prog langs providing a set of APIs in the stdlibs, that are officially blessed to be maintained. They might not be the best designed, but they are guaranteed to work for a long long time. This kind of trust is very hard to build for 3rd part libs. It's a trade-off to make, and rust for now has decided to keep stdlib lean and quick to iterate over. But I hope at some point, Rust devs would consider including more APIs.

I think that the rust-lang-nursery Github organization[1] is designed to solve part of the trust issue. A lot of the "batteries" crates are in there; `rand`, `futures`, `error-chain`, `lazy-static`, `glob`, `bitflags`, and `log` catch my eye after looking through. In the long run, I don't think that having things like the blessed HTTP library being third-party will be that much of a detriment; at least when I was writing Python, almost everyone I knew used the `requests` library, and nobody worried about it not being part of the standard library.

What sort of maintenance is actually needed though?

Rust promises that existing versions of crates will build and run in the future, assuming the crate is well-behaved and doesn't do anything illegal with unsafe code. That's part of Rust's general stability guarantee.

Maybe "blessed to be maintained" means crates get ongoing critical security fixes? Thanks to Rust, for most crates that's a very low-probability concern. (Obvious exceptions for features like HTTP and TLS that contain their own security decisions.)

Maybe you mean that all kinds of bugs will continue to be fixed and the quality of the crate will keep increasing? I don't think any languages really give you that; they all have standard library features that are effectively end-of-life. A lot of application developers don't even WANT such fixes since there's always a risk of breaking previously-working applications.

So I think it would make sense for the Rust community to commit to a subset of crates for ongoing maintenance, but for probably the majority of crates you could just keep using the exact same version for the next five years with no worries.

But the versioning guarantees are _exactly_ why having them in the stdlib would be good for me as a user; it means I'd be able to have code that keeps working, but have new improvements available.

It's totally fine to decide to make the trade off, but it's just frustrating to not have the downside acknowledged.

As long as you don't use "*" as the version for any of the crates in your project's Cargo.toml it should stay at one particular version and therefore follow SemVer guarantees. If you are REALLY paranoid, you can even have the crate be a particular git commit or you could download your preferred version and then refer to it using the "path" key in the Cargo.toml.

Adopting crates into the stdlib would make stdlib and the crate depend on each other, which is not a nice scenario. Also having certain "core"-functionality be dependent on a 6wk release cycle is not great for stuff that is not good once it's set in stone (aka released on stable).

Real core functionality, bare bones stuff like parsing of Rust itself, I/O and TCP/UDP connectivity, which provide an unlikely to ever change framework for crates to build upon rightly has its place in std; e.g. convenience methods for downloading (like what reqwest provides) OTOH have to stay flexible to adapt to the real world.

Yeah, but 20 years down the road, you're either going to be writing the same code or sifting through piles of crufty bad stuff.

Do you know where I can find the comment about no plan for Rust 2.0? I tried googling it but I couldn't find it. Reason why I'd like to find it to have some guarantee that this is true.

Cause it sounds like a strong commitment here.

https://github.com/rust-lang/rfcs/blob/master/text/2052-epoc...

Though we are calling them “editions” instead of “epochs” now.

Reply on news.ycombinator.com