How would that work on embedded? It is not like you could run tokio on a microcontroller, nor embassy on a server.
If I'm understanding @harmic's proposal correctly, you'd have a rust-lang.org page of "recommended server crates", where crates like Tokio, Serde, and other "choosing an alternative will make your life harder" crates would be listed.
You can then similarly have a page for "recommended embedded crates", where you list things like embedded-hal and Serde (again), as crates where choosing something else is possible, but will make your life harder.
You would not, however, put peripheral access crates, or parsing crates, or anything else that doesn't affect dependency choices on this list. It may (or may not) be true that nom is everyone's preferred parser crate, or that everyone using the AHT20 I2C temperature sensor uses the aht20 crate to interface to it, but because those crates don't provide ecosystem-pervasive data types or traits, they're not suitable for the list.
The idea is to steer someone new to a specific area away from choices that will make their life harder in future, and towards whatever the ecosystem as a whole has chosen, while leaving the choice free for anything where you're not going to make your life harder in future by choosing the "wrong" crate.
6 Likes
I'm hoping we eventually have a standard one as part of std, in addition to facilitating interoperability between runtimes.
1 Like
The "picking a winner" thing is an off-topic distraction here. Recommendation of 3rd party "winner" crates is not what I've been asking about — by definition they aren't first-party Rust-lang crates owned and maintained by the Rust-lang org.
6 Likes
You can check the Rust team database (team/repos/rust-lang at master · rust-lang/team · GitHub) to see who has permissions to maintain/perform releases for each repo. There are still repositories owned by individuals or that don't have any branch protections, these don't provide that many guarantees. On the other hand, there also repositories to which only some of the "official" Rust Project teams have access, they are protected by branch protections, and deployment is handled automatically from CI (usually based on git tag pushes, see Automate crate deployment · Issue #117 · rust-lang/infra-team · GitHub). These are a bit more locked down.
Not sure if you want to base the "officiality" of a crate on its GitHub permissions though 
1 Like
How would that work on embedded? It is not like you could run tokio on a microcontroller, nor embassy on a server.
There are two parts I think. The first is that std is missing some key traits - a way to spawn tasks, for one, and async read / write for another. In the absense of these traits, different runtimes have implemented different interfaces.
The other is a reasonable default runtime - one that is good enough for the majority of use cases. This would be very helpful for newcomers who really are not equipped to choose among a set of competing and partially incompatible choices.
My preference would be for the 'default runtime' to be owned & maintained by the rust project, to guarantee its stability and some level of maintenance. I guess having a runtime endorsed by the rust project could also work.
As I mentioned in my earlier comment: this does not preclude other runtimes more suited to other use cases (I specifically mentioned embedded there). Standardized traits for key interfaces should make interchanging runtimes more feasible.
I know these topics are under discussion in the async workgroup.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.