I've started some effort to help people to get an overview about Rust projects suitable for embedded Linux device development: fkromer/best-of-rust-on-embedded-linux I'm happy to merge your PRs!
There are some errors I see right away: Slint isn't unlicensed. Rather it is dual licensed GPL3 or commercial for embedded. See slint/LICENSE.md at master · slint-ui/slint · GitHub
Thx for the hint. The markdown is automatically generated based on the projects.yaml content. This issue should be reported in issue · best-of-lists/best-of. Here we go: Fix license extraction · Issue #227 · best-of-lists/best-of
@fkromer, are you familiar with the Awesome Rust Embedded list? It's maintained by the Embedded Rust Working Group. If so, what distinguishes your list?
Yes, I know the project. I've trouble to separate projects targeting microcontrollers (e.g. Cortex-M architecture) from projects usable in embedded Linux projects (e.g. ARM architecture). In general it's pretty cumbersome to figure out what architectures are supported by a specific crate (there is no "architecture" filter option from crates on Crates - crates.io: Rust Package Registry. (That's a generic problem. There is also no filter for architectures on PyPI: Python Package Registry)
One way of communicating architecture support explicitly is to add best-of-lists/best-of-generator labels corresponding to architectures a project is known to support.
ATM OpenEmbedded Layer Index - meta-rust (OE is the build system used in the Yocto project e.g.) is no good indicator for embedded Linux compatibility as well... it's pretty empty. (OpenEmbedded Layer Index - meta-python contains at least some well known packages.)
What do you mean with "embedded Linux compatibility"? It's Linux, the "embedded" part is usually a red herring.
The reason meta-rust doesn't have crate recipes is that adding them would be almost as painful as adding npm package recipes, you'd need to add essentially the whole registry. For Python the included packages generally might only have a handful of dependencies in addition to the standard library so it's more or less manageable, but not fun nor convenient. Additionally, since PEP-517 I think the direction has been toward package management even with Python. See for example python_pep517.bbclass. Similarly there's cargo.bbclass because people don't want to maintain bitbake recipes for crates (or python / npm packages for that matter).
In general, bitbake's standard approach (download -> unpack -> configure -> compile) is not very well suited for languages with package management where you first need to download and unpack the sources to be able to determine what dependencies are needed.
As for your list of good embedded Linux (I'll take this to mean you want to cross compile something) projects I can mention cross-rs and other than that I'd suggest creating a good tutorial on how to do Rust development against Yocto based distributions. The usual hurdles apply if you're cross compiling: deploying, debugging, maintaining SDKs and so on.
What do you mean with "embedded Linux compatibility"? It's Linux, the "embedded" part is usually a red herring.
With embedded Linux I mean CPU architectures usually used in embedded Linux devices. Those are e.g. armv7l (32 bit), armhf, arm64/aarch64, riscv32, riscv64, ... Usual servers may (but usually do not) use those architectures as well of course.
The reason meta-rust doesn't have crate recipes is that adding them would be almost as painful as adding npm package recipes, you'd need to add essentially the whole registry. For Python the included packages generally might only have a handful of dependencies in addition to the standard library so it's more or less manageable, but not fun nor convenient. Additionally, since PEP-517 I think the direction has been toward package management even with Python. See for example python_pep517.bbclass. Similarly there's cargo.bbclass because people don't want to maintain bitbake recipes for crates (or python / npm packages for that matter).
It's absolutely reasonable why the ecosystems are how they are. Actually I wonder why meta-python provides so many package specific recipes. If you are used to web backend application development you know how many dependencies you can end up depending on in an application. If you want to migrate a RESTful API server developed on the host into an embedded device for example it's pretty cumbersome to do so. It's difficult to ensure that the package dependencies of the application developed in the host match with those provided by meta-python. In the end you usually need to get those host specific dependency versions into an image in an application specific, custom way anyways.
One potential solution to overcome the package dependency issue is to use docker containers in the device (e.g. balenaOS). Or to convert "Docker" containers into linux containers and deploy those onto devices (e.g. pantavisor). The challenge of not having knowledge about if the source code of a crate compiles on a specific architecture or not remains however.
In general, bitbake's standard approach (download -> unpack -> configure -> compile) is not very well suited for languages with package management where you first need to download and unpack the sources to be able to determine what dependencies are needed.
I know. This is actually a common argument against using the Yocto project. Until you've not tried to compile a package for an architecture you don't know if it will work for sure. This makes early design decisions impossible. In contrast Debian provides architecture compatibility information for packages (rkflashtool supports arm64, armhf, ... for example). On the other side the Yocto has other advantages of course (better reproducibility, ...).
As for your list of good embedded Linux (I'll take this to mean you want to cross compile something) projects I can mention cross-rs and other than that I'd suggest creating a good tutorial on how to do Rust development against Yocto based distributions. The usual hurdles apply if you're cross compiling: deploying, debugging, maintaining SDKs and so on.
cross-rs is already contained in the cross compilation section 
In an ideal world there would be a "crate architecture compatibility test" project run by the cross-rs or embedded rust group which tries to compile all potentially interesting crates for all supported architectures. As a result there would be a compatibility table indicating if a particular crate can be compiled against a specific archiecture or not.
...or the Yocto project would run such a project. From the Rust community point of view this would be less helpful however cause Yocto project specific.