4 ms·
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard
by kd5bjo 7y ago
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months.
Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes explicit future compatibility policies. Unfortunately, I can’t find an index of only the crates maintained by the Rust team.
Serde is obviously popular, but at first glance is a giant Swiss Army knife that will likely have lots of updates to keep track of that are completely unrelated to my project (whatever it is). If I search for JSON, I get an exact match result of the json crate, followed by a bunch of serde-adjacent crates, but not serde itself.
Request hasn’t been updated in 4 years, and has a total of less than 7000 downloads.
- Freak_NL 7y agoThat sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.
- kd5bjo 7y agoIt’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them. Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experimental library is the right choice. The trouble is figuring out which I’m looking at.
- xenocratus 7y agoI'm not sure I follow these concerns about "working in the future" - as long as you specify versions that work for you in your Cargo.toml file, that should work at any point in the future given that you use Rust 1.x. If you'll want to update to always be on the latest version of each crate, well that discomfort about them potentially not working is part of the price.
- kd5bjo 7y agoIf I come back to something, it’s because I want to resume active development. Keeping a dependency pinned at an old version makes that more difficult in various ways, so I personally value forward compatibility. Not everyone does, and that’s fine. I just want to know what a library developer’s stance on it is before I try to use their library.
- roblabla 7y agoThis was attempted by the Libz Blitz back in 2017. See the rust-cookbook: https://rust-lang-nursery.github.io/rust-cookbook/ https://rust-lang-nursery.github.io/rust-cookbook/ . I agree that this should be better documented and probably more integrated with crates.io somehow.
- p0nies 7y agoAnyone can search for "awesome [lang]" when they want such a thing.
- throwaway8941 7y agoBecause it's "reqwest", not "request". All these libraries are very well known within the community and are what I would come up with as a complete outsider (I don't think I've written more than a hundred lines of Rust code to this date). You can also find some pointers here: https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust https://lib.rs https://lib.rs
- roblabla 7y agoThere's actually a more official resource: the rust cookbook[0]. This is maintained by the rust-lang team (rust-lang-nursery is an official place for crates maintained by the rust language maintainers). [0]: https://rust-lang-nursery.github.io/rust-cookbook/ https://rust-lang-nursery.github.io/rust-cookbook/
- nicoburns 7y agoThey probably meant reqwest (https://github.com/seanmonstar/reqwest https://github.com/seanmonstar/reqwest), not request. Reqwest is maintained by the same developer (seanmonstar) as hyper, the de facto standard http library.
- swsieber 7y agoAh, I did. I posted that on my phone. Autocorrect strikes again.