2 ms·
My personal opinion on each of those: JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde
by bilkow 1mo ago
My personal opinion on each of those:
JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs.
regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trust std, you trust the rust-lang organization anyway), but without the issues of being in std (backwards compatibility and bloat). The only problem I see with that is that BurntSushi is still the owner of the package and as such can still publish new versions on his own (AFAIK crates.io currently requires at least one user owner, but that's something that can be solved by improving crates.io permissions).
walkdir: It has been been postponed, due to the complexity of WalkDir, but may be added in the future. I agree this should be in std. https://web.archive.org/web/20260820171531/https://github.com/rust-lang/libs-team/issues/677#issuecomment-3428945051 https://web.archive.org/web/20260820171531/https://github.co...
RNG: rand is still evolving, with breaking changes half a year ago. Preferred generators tend to change over time, so I don't see those getting into std (remember, it has to be maintained forever!). I could see the interface (traits) getting into std, but I see no advantage to it: it's maintained by rust-random, but even if you wanted it to be maintained by the same authors as the Rust language (let's say you trust them more than rust-random), you could just move it back to rust-lang-nursery or rust-lang.
CLI arg parsing: not simple at all! The community's preferred solution has 70kLOC (with support for so many features), but there's also argh, pico-args, and others, each with their own tradeoffs.
> That's why projects end up with 100s of crates, sometimes 1000s.
Also because libraries are split up in many crates. For example, regex is split in 3 crates: regex, regex-syntax and regex-automata, and depends on other crates from the same author, such as aho-corasick.
All that said, there are many crates, such as algorithms like aho-corasick, that I think could me moved into the rust-lang org, like regex was.
See also: https://home.expurple.me/posts/a-big-standard-library-is-overkill/ https://home.expurple.me/posts/a-big-standard-library-is-ove...
- kibwen 1mo agoOn the topic of RNG, the functionality of the getrandom crate is getting ready to be exposed from libstd: https://github.com/rust-lang/rust/pull/157168 https://github.com/rust-lang/rust/pull/157168
- imtringued 1mo agoA big issue here is the complete lack of namespacing. You have these sub crates with zero ability to know whether they are related to a given organization/author/project. I mean look at the people defending the lack of namespacing: https://samsieber.tech/posts/2020/09/registry-structure-influence/ https://samsieber.tech/posts/2020/09/registry-structure-infl... One of the most obvious problems with the lack of namespacing is that if you have a group of crates belonging together, you have to reserve them all at once otherwise an automated script could detect your package and add common suffixes like -sys and take the name even though you got the non sufficed name. You cannot add name spacing by just prefixing everything with your preferred prefix, because anyone can publish under that prefix.