3 ms·

Yeah, IMO the small standard library in Rust is a big mistake, one of the few the language has made. When push comes to shove the stdlib is the only thing you c

by bigstrat2003 8mo ago

Yeah, IMO the small standard library in Rust is a big mistake, one of the few the language has made. When push comes to shove the stdlib is the only thing you can count on always being there. It's incredibly valuable to have more tools in the stdlib even if they aren't the best versions out there (for example, even if I normally use requests in Python urllib2 has saved my bacon before), and it doesn't hurt anything to have them there.

hombre_fatal 8mo ago
On the other hand, a worse implementation in the stdlib can make it harder for the community to crystalize the best third-party option since the stdlib solution doesn't have to "compete in the arena". Go has some of these. Maybe a good middle-ground is something like Rust's regex crate where the best third-party solution gets blessed into a first-party package, but it is still versioned separately from the language.
jabl 8mo ago
I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib. With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it. Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see. But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?

hombre_fatal 8mo ago

On the other hand, a worse implementation in the stdlib can make it harder for the community to crystalize the best third-party option since the stdlib solution doesn't have to "compete in the arena". Go has some of these. Maybe a good middle-ground is something like Rust's regex crate where the best third-party solution gets blessed into a first-party package, but it is still versioned separately from the language.

jabl 8mo ago

I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib. With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it. Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see. But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?