| ▲ | hacker_homie 14 hours ago |
| Move high value crates into the standard library? |
|
| ▲ | kibwen 11 hours ago | parent | next [-] |
| Indeed, I'm all for maximizing the amount of modules in the standard library. It's pretty obvious to me that Python thrives because of, not despite of, its standard library, "dead batteries" and all. However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize... In particular, most recently the aforementioned release stabilized the cfg_select! macro for convenient conditional compilation, which obviates the popular cfg_if crate: https://doc.rust-lang.org/stable/std/macro.cfg_select.html |
|
| ▲ | SAI_Peregrinus 9 hours ago | parent | prev | next [-] |
| An extra tier of standard library which can make breaking changes, perhaps. Rust's stability guarantee for std means cryptography really shouldn't go in there, since sometimes algorithms & protocols get broken (DES, MD5, SHA1, etc.) and need to be removable. Without breaking changes you get stuck with security vulnerabilities, if not from cryptography then from other poorly-designed APIs. |
|
| ▲ | hacker_homie 14 hours ago | parent | prev | next [-] |
| Maybe give crates a gold star if they have no external dependencies? |
| |
| ▲ | sdenton4 12 hours ago | parent | next [-] | | That's not at all a bad idea, imo. And a silver star for crates which only depend on gold star crates... | |
| ▲ | mmastrac 10 hours ago | parent | prev | next [-] | | It's hard to have zero deps - I put many hours into one to have no required deps in the end but it was not easy, and writing declarative macros to do anything complex takes work (and a proc macro often means a minimum of two crates). Both of the crates it requires are part of the same project, however. One of my other crates (getaddrinfo) requires windows-sys and libc which would be challenging to get rid of. I like the idea of low deps but zero is tough https://crates.io/crates/ctor/1.0.4/dependencies | |
| ▲ | rcxdude 6 hours ago | parent | prev [-] | | This only encourages rewriting perfectly fine libraries badly. There's no simple metric to actually optimize here. |
|
|
| ▲ | orf 14 hours ago | parent | prev | next [-] |
| Please no, that’s a terrible outcome. |
| |
| ▲ | pixl97 13 hours ago | parent [-] | | What else would you suggest that also does not have terrible outcomes. The situation as is, is untenable. | | |
| ▲ | vsgherzi 12 hours ago | parent [-] | | As I said above “Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.” This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team |
|
|
|
| ▲ | vsgherzi 14 hours ago | parent | prev [-] |
| This bloats the std library and forces lots more work and stress on the rust dev team. Not to mention it’ll add more churn to the std lib. |
| |
| ▲ | jcgl 12 hours ago | parent [-] | | One man's bloat is another man's batteries-included, I guess? My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild. | | |
| ▲ | vsgherzi 12 hours ago | parent [-] | | The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the crypto library causing churn in the ecosystem. |
|
|