The problem of duplication of crates and ensuring re-use

[DrizztVD1]

Continuing the discussion from Rust beginner notes & questions:

Rust beginner notes & questions

I see people reimplementing identically named but incompatible traits as a failure: dual_num::Zero - Rust I know that sounds harsh and nit-picky, but I feel that it's a sign of things to come. This kind of thing will inevitably get worse as a consequence of stripping low-level abstractions out of std. The missing wheels will be reinvented, and it's going to be a huge, incompatible mess. (To clarify: I'm not generally advocating for std to include all-encompassing implementations for things, b…

Rust beginner notes & questions

That's not a different trait; it's a re-export of the Zero trait from num-traits. It would be nice if rustdoc had some way to indicate this.

[gilescope]

If we go down the route of a small standard library which seems to go with Rust's 'pay only for what you use' mentality, we do need to have a way to highlight great crates in certain areas.

At the moment we have a reasonable amount of crates but the quantity is growing all the time. A new user needs to know not just that it's production quality (version >= 1) but also whether its a good choice.

As we're not having batteries included could we have a batteries recommended approach?

Possibly something like this for crates:

Elixir vs Golang vs Rust | What are the differences?

(but with a bit more curation care.)

We all collectively have a lot of knowledge that would be good for new rustations to be able to tap into when they're starting out or branching into an area they've not been into before. At the moment we ad-hoc ask in forums what's a good crate for X. I wonder can we formalise that?

Maybe crates should allow user reviews: "I used Serde 0.9 but it ate my hamster" - feedback from the field of how they used a crate could be helpful and a great source of tips.

[kornel]

I've created https://crates.rs to experiment with such things. The code and data is open, so you can play with finding better ways to expose good crates.

[bgeron]

There is stdx:

GitHub - brson/stdx: The missing batteries of Rust

[DrizztVD1]

Hurray! Note: last updated one year ago.

[gilescope]

Yes, I did wonder if failure crate should get a mention as an alternative to error-chain.

stdx seems like a good collection of batteries.

[carols10cents]

@gilescope

We all collectively have a lot of knowledge that would be good for new rustations to be able to tap into when they’re starting out or branching into an area they’ve not been into before. At the moment we ad-hoc ask in forums what’s a good crate for X. I wonder can we formalise that?

This is what the Rust Cookbook is intended to be

[DrizztVD1]

Discoverability of existing tools and documentation, and the purpose of such documentation, is perhaps too low. Perhaps a more comprehensive overview of the Rust procedures and community how-tos could be added at around the start of the Rust Programming Language Book?

i.e 1) How the community works,
2) how to contribute to rust and all relevant guidelines, and
3) where community discussions occur and its code of conduct.

[gilescope]

My document expectations have grown so much thanks to Rust!

I'd love to see cargo doc generated doc search engine be able to as well as dependent crates (which is full on awesome) search local std docs and ideally the rust programming language and cookbook (if they're locally installed).

For me that would be having and eating my documentation cake.