Commonly used crates should be blessed and go into an extended stdlib.

Ok, but this is not a commonly used crate. Its brand new!

alfiedotwtf 8 hours ago | parent | prev | next [-]

Unless there’s a strict schedule for review to remove them, please no… because that’s how we get BerkeleyDB and CGI in the standard Perl libraries.

If anything, there should be “less than blessed” “*-awesome” libraries

▲

echelon 9 hours ago | parent | prev [-]

No HTTP, Proto, or gRPC crate should ever find itself in the stdlib.

Didn't we learn this with python?

How many python http client libraries are in the dumping ground that is the python "batteries included" standard library?

And yet people always reach for the one that is outside stdlib.

▲

kjuulh 7 hours ago | parent | next [-]

On the other hands, having half the packages depend on packages such as serde, syn, procmacro2 might not be such a good idea. First of all it is annoying when creating new projects to have to move over table stakes. Second, it is a security nightmare. most of rust could be vulnerable if dtolnay decided to go rogue.

It is not that everything should go into the stdlib, but having syn, procmacro and serde would be a good start imo. And like golang having a native http stack would be really awesome, every time you have to do any HTTP, you end up pulling in some c-based crypto lib, which can really mess up your day when you want to cross-compile. With golang it mostly just works.

It isn't really in the flavor of rust to do, so I don't think it is going to happen, but it is nice when building services, that you can avoid most dependencies.

▲

bigfishrunning 2 hours ago | parent [-]

I agree with this. Rust has a node-style dependency problem; any non-trivial rust project ends up with dozens of dependencies in my experience. I would add tokio to the list of dependencies-so-common-they-should-be-moved-to-stdin.

A second tier stdlib would turn out like the Boost c++ libraries -- an 800 lb gorilla of a common dependency that gets called in just to do something very simple; although to be fair most of the Boost functionality already is in rust's stdlib.

	▲	SAI_Peregrinus an hour ago \| parent [-]
		As long as the "2nd-tier" stdlib was versioned & tied in with the edition system, it could work. The problem with most stdlibs (including Rust's) is that there's no way to remove anything & replace it with a better design. So the lib only ever grows, slowly adding complexity.

▲

Valodim 8 hours ago | parent | prev | next [-]

You don't think golang's http library is a good idea? I would have thought everyone is happy we have it

	▲	arlort 2 hours ago \| parent [-]
		Would it be still a good idea if instead of being created / owned by google as an organization it was originally made by someone that didn't make billions by handling trillions of http requests over decades and you had to keep all of the bad initial api design choices going forward?

▲

j1elo 7 hours ago | parent | prev [-]

I would always go to the official docs page for the needs I have, and use their HTTP library (or any other). It removes decision making, having to ensure good quality practices from lesser known libraries, and risks of supply chain attacks (assuming the root stdlib of a language would have more attention to detail and security than any random 3rd-party library thrown into github by a small group of unpaid devs)

Only when it falls short on my needs, I would drop the stdlib and go in dearch of a good quality, reputable, and reliable 3rd-party lib (which is easier said than done).

Has worked me well with Go and Python. I would enjoy the same with Rust. Or at a minimum, a list of libraries officialy curated and directly pointed at by the lang docs.