Tracking the Ecosystem: Which important crates are missing?

The crate ecosystem is growing rapidly, but is still rather immature.

This thread is supposed to track which stable and high quality crates all of you are missing the most,
with the purpose of guiding developers/volunteers to what is needed, where they could contribute, and to track progress.

It would be great if everyone could describe what functionality/crates you think are needed the most.

I will update the original post with a list, sorted by votes/mentions.

  • Describe the crate you need
  • (Optional:) List existing crates and why they are not sufficient
3 Likes

I'd like to see a mature crypto library, it seems like a perfect use-case of Rust's safety and performance. A lot of the more mature libraries are just thin wrappers around existing crypto libraries, or are abandoned. I doubt we'll get one any time soon though; Crypto is hard to get right and is probably not going to be worth the amount of time it takes to start a new project from scratch. For now I've been using ring, it's simple to use and well documented.

1 Like

Not necessarily a crate, but rather an up-to-date discussion/documentation of the Rust ecosystem for asynchronous IO (both network and disk) and parallel computations. In the past, there was http://areweconcurrentyet.com/, but the website is now offline and the associated github repo has been devoid of activity for a while.

3 Likes

RustCrypto aims to fill this gap and create an ecosystem of crypto crates written in pure Rust. Though it definitely has a long way to go before it can be called "mature", as for now even not all algorithms from the rust-crypto were ported.

Regarding performance, unfortunately, it's not that easy and using assembly (i.e. ring's way) is the only reliable way to get the best performance.

And as for safety, there is a lot more to safety in crypto implementation context, not just a memory safety. And some things can't be done reliably in the current Rust. (e.g. zero on drop or enforcing constant execution time)

1 Like

FWIW, there is twice as much Rust as C code in ring already, so it really isn't a "thin wrapper". The amount of assembly language code in it dwarfs both the Rust and C code, though. ring's goal is to maximize safety without compromising performance in any significant way, which is why we have so much assembly language code. There are already other “pure” Rust crypto libraries if you don't care so much about performance.

4 Likes

The lack of low-level input handling libraries is kind of a non-starter for game development - not just gamepads or joysticks, but keyboards, mice, HID devices in general really. Existing crates are either too high-level, wrappers around C libraries, not cross-platform, abandoned, or some combination of the four. It's a huge shame because I think Rust has enormous gamedev potential, but there doesn't seem to be a whole lot of interest in improving things in this area.

3 Likes

I would like an infallible JSON value conversion crate. Basically rustc_serialize::json::ToJson but for serde_json::Value.

With serde_json::to_value you get a fallible conversion that may fail for example because the input is a mutex that is poisoned, or because the input is a map with non-string keys, or for any number of other reasons. In some situations you want the type system to guarantee that the conversion cannot fail in those ways.

An infallible conversion would require its own custom derive. Something like:

#[derive(ToJson)]
struct S<T> {
    a: String,
    b: T,
}

// expands to
impl<T> ToJson for S<T> where T: ToJson {
    fn to_json(&self) -> serde_json::Value {
        let mut map = serde_json::Map::with_capacity(2);
        map.insert("a", self.a.to_json());
        map.insert("b", self.b.to_json());
        serde_json::Value::Object(map)
    }
}
1 Like