[burntsushi]

(I've been on libs-api, and libs before that, for 10 years now.)

API Stability. When the standard library APIs were initially designed, "the Python standard library is where packages go to die" was very much on our minds. We specifically saw ourselves as enabled to have a small standard library because of tooling like Cargo.

There are no plans for Rust 2.0. So any change we merge into std is, effectively, something we have to live with for approximately forever. (With some pedantic exceptions over edition boundaries that don't change my overall point.)

Nuance is nearly dead on the Internet, but I'll say that I think designing robust and lasting APIs is a lot harder in Rust than it is in Go. Rust has a lot more expressiveness (which I do not cite as an unmitigated good), and the culture is more heavily focused on zero-overhead abstractions (which I similarly do not cite as an unmitigated good). That means the "right" API can be very difficult to find without evolution via breaking changes. But the standard library cannot, generally speaking, make breaking changes. Crates can.

I would suggest not reading the OP as a black-and-white position. But rather, a plea to change how we balance the pros and cons of dependencies in the Rust ecosystem.

[WhyNotHugo]

I can understand not wanting to add SMTP or CGI to the stdlib. But a lot of common POSIX functionality (which is sometimes a single syscall away) is missing too.

[burntsushi]

A lot of common POSIX functionality is not missing though. I was able to write ripgrep, for example, by almost entirely sticking to the standard library. (I think the only place I reach out to `libc` directly is to get the hostname of the current system for rendering hyperlinks in your terminal.)

We also came at the standard library with a cross platform mentality that included non-POSIX platforms like Windows. You want to be careful not to design APIs that are too specific to POSIX. So it falls under the same reasoning I explained above: everything that goes into std is treated as if it will be there forever. So when we add things to std, we absolutely consider whether the risk of us getting the API wrong is outweighed by the benefit of the API being in std in the first place. And we absolutely factor "the ease of using crates via Cargo" into this calculus.

[WhyNotHugo]

I peeked at the code for gethostname in ripgrep, and it's nice and straightforward.

Much like op said here; we have a culture of "don't write unsafe code under any circumstance", and we then pull in a dependency tree for a single function that's relatively safe to contain. It solves the problem quickly, but at a higher price.

BTW, thanks for ripgrep. I don't actually use it, but I've read through different portions of the code over recent months and it's some very clean and easy to understand code. Definitely a good influence.

[ziml77]

I don't think you should treat unsafe code as that level of toxic. It's necessary when interfacing with with system APIs. The important part is that you try to have safe wrappers around the unsafe calls and that you document why the way you're using them is safe.

[palata]

I've been using ripgrep for years! Thanks a lot for that!