[cle]

There’s a third option if the package is so important: put it in the standard library.

Technically it’s still a dependency but the standard library is maintained with a standard that is rarely matched by third party libraries, and can dramatically simplify the ecosystems’ dependency graph.

[the8472]

Rust's standard library is intentionally kept small since it's initially not always obvious what the best solution is and the stability guarantee makes it the wrong place for evolving, diverse or opinionated APIs.

E.g. the async ecosystem offers you to pick between runtimes of different complexity and tradeoffs. Std only picked up the essential traits that allow other crates to interoperate with each other and the language itself to define async functions.

[ccktlmazeltov]

hopefully at some point they start including more batteries

[steveklabnik]

> with a standard that is rarely matched by third party libraries

I mean, you can go both ways with this. Standard libraries are significantly more difficult to work on than third party libraries, and I've seen a lot of code in standard libraries that is objectively worse than ecosystem equivalents because of it.

[cle]

I agree, there's no silver bullet, only tradeoffs and our appetites for them.

From looking at the list of crates above, I see a lot that are often part of the stdlib of other languages, such as HTTP, concurrency/nio primitives, and logging.

My perception of Rust's not including such fundamental primitives in the standard library is that Rust is still very much experimental, and the ecosystem values tinkering and experimenting with new ideas. The cost of that is increased dependency hell, especially over time. There's obviously huge value in experimentation for the industry, but it makes me hesitate to use Rust for projects where I just need to get stuff done, and stay done.

[steveklabnik]

HTTP libraries are a prime example of where many, many standard libraries are considered old and crufty, and there are much better ecosystem libraries that end up being wildly used more.

You may have that perception, and that is fine, but it's not likely to be a thing that changes significantly, even when Rust is quite old. There's just not a lot of advantage to being in the standard library, and numerous downsides.

[cle]

We should be more nuanced than that. There are also many standard libraries where the HTTP implementation is the standard. Why?

> There's just not a lot of advantage to being in the standard library, and numerous downsides.

Look at those huge lists of dependencies and the complaints of Cargo dependency hell. That's the downside. Every node in your dependency graph has overhead for everyone involved, and it's even worse when it's something as fundamental as HTTP.

[steveklabnik]

Yes, there are downsides to every approach here. That's just life.

I write a lot of Rust that never touches HTTP.

[tracker1]

Isn't that exactly why you'd use a package like hyper that wraps the pieces together for you?

I'm less experienced with rust, but with nude, there's many times I'll use a specific dependency over another because it's already in the dependency tree.

Aside, it's rough actually trying to keep node dependencies in check in a project. Especially in web UI projects using npm.

[tracker1]

As inconvenient as it is, I tend to agree. Having worked with C#/.Net where almost everything in the box, Node, where very little is in the box and a miniscule amount of rust which is more towards the latter, I prefer the latyer.

Now, I am somewhat supposed that say tokio or similar hasn't made it in the box yet, it allows for much greater experimentation.

Aside, I wouldn't be surprised to see MS generate a massive sure if libraries if they shift more internals development to rust. Not sure if it'll be good/bad or otherwise.

[ccktlmazeltov]

Go disagrees with you

[nextaccountic]

Currently the mpsc channel on the stdlib is worse than the one found on crossbeam (according to the author[0]). That's one data point.

[0] https://internals.rust-lang.org/t/scaling-back-my-involvemen...