[RFC] Curated list of projects

[japaric]

We have a curated list of crates and tools in awesome-embedded-rust but there's an opportunity for
also showing embedded Rust projects in a more compelling manner than just a bullet list.

Let's make a web page that list projects with pictures and videos! And link it from the embedded WG
web page that will be on rust-lang.org

Here's a detailed strawman proposal to get the conversation started

Repository name

"Made with embedded Rust" OR "Awesome embedded Rust projects"

Project submission requirements

• Obviously, it must involve hardware that runs Rust code.
• Must compile on stable by Rust 1.31.
• The code must be public.
  • I feel this is very useful for developers that want to see how an embedded Rust application is
    structured

Submission format

• Project name
• Author name
• Project website (+ link to repo) OR project repository
• Project description
• Image, GIF or video of the hardware

Unresolved questions

At what point do we consider something a "project"? Do we consider the examples of a board support
crate as a "project" that can be submitted here? Do we consider a book a "project" too?

Should we limit submissions to projects that are "done"?

Thoughts?

cc @rust-embedded/resources @andre-richter @jamesmunns @therealprof
cc @cr1901 @thejpster

[little-arhat]

Why "Must compile on stable by Rust 1.31" requirement for projects (as opposed to tools/libs)?

[japaric]

Why "Must compile on stable by Rust 1.31" requirement for projects (as opposed to tools/libs)?

Because they will be showcased as examples to follow or to use as reference -- people will read
the source code. As such the projects should showcase good programming practices and at a minimum we
should show that one does not need to rely on something that will break tomorrow to write embedded
Rust applications.

Furthermore, I'm pretty sure plenty of people will try to build the projects for several reasons:
because they heard that Rust makes cross compilation is easy and that the build system is great, or
perhaps because they want to check that the binary artifacts are small. Whatever the reason, it
would be pretty bad if they try and the project fails build on stable.

On the other hand, most people won't be reading the source code of the tools and libraries they use.
Tools don't need to compile on stable to be used with a stable toolchain. And if a library doesn't
compile on stable you can look for an alternative on crates.io.

Of course, this is my opinion. If the majority thinks that "compiles on stable" should not be a
requirement then I'll concede.

(off-topic: I'd like to see all the libraries listed in awesome-embedded-rust marked as "compiles on
stable 1.xy" or "requires nightly". I know there's no automatic way to do this but we could do it as
a community-wide effort during the last 6 weeks before the 2018 edition final release).

[therealprof]

I'm also not convinced (yet) that all features required to build the most impressive embedded applications will be available in stable from the get go. Plenty of applications and tools in the rust universe faced the same problem for a while, e.g. the derive feature of serde.

(off-topic: I'd like to see all the libraries listed in awesome-embedded-rust marked as "compiles on
stable 1.xy" or "requires nightly". I know there's no automatic way to do this but we could do it as
a community-wide effort during the last 6 weeks before the 2018 edition final release).

I agree.

[andre-richter]

Yeah, we should be pragmatic here imo. To me, in the current state of Rust, pragmatic means making stuff accessible to people in the most easy way possible.

If there is hardware that people are interested in for running demos, we shouldn't gate them by excluding cool projects that happen to have some dependency on non-stable Rust.
But of course it is an advantage if it is stable-Rust ready.

[japaric]

Nominating for discussion in the next meeting (#150)