Three biggest Rust frustrations when creating the Bed-Reader extension

\[Background: Bed-Reader is a Python bioinformatics project, written in part with Rust. link, alt link\]

I was asked in another forum about what in Rust I found most frustrating when writing Bed-Reader. Here is what came to mind:

"nice" Rust errors - It took me a long time to figure out how to get nice errors in Rust. I wanted to return system errors (e.g. file open not finding a file) and custom errors (e.g. file in the wrong format). I also wanted all the errors to have nice error messages. As mentioned in the article, I ended up using the "thiserror" crate and creating an enum called BedErrorPlus. BedErrorPlus included std::io::Error, ThreadPoolBuildError, and BedError. Finally, BedError contains all my custom errors. This seems like the way everyone should handle errors, but I only found one resource that explained it. (Rust: Structuring and handling errors in 2020 - Nick's Blog and Digital Garden)
par\_azip! and returning errors -- ndarray::parallel's par\_azip! macro is, I think, the most readable way to data parallelize array-related code. However, the documentation and examples for it are very sparse AND maybe it should be part of Rayon (not just ndarray::parallel) AND it doesn't have a direct way to return errors. (The article gives a work-around way to return errors).
traits for numerics -- it took a long time for me to figure out the traits to create a generic function that would cover i8, f32, and f64. I ended up (after a lot of trial and error) with Copy + Default + From<i8> + Debug + Sync + Send