What does HackerNews think of awesome-embedded-rust?
Curated list of resources for Embedded and Low-level development in the Rust programming language
Re code examples - Here's the Rust Awesome Embedded List - a collection of tools (especially hardware support drivesr) - https://github.com/rust-embedded/awesome-embedded-rust
Most of them aren't suitable for use in practical projects; they're missing important features like non-blocking operation, low-power modes, DMA etc - these are all things that will come up in embedded projects, but aren't needed for the "hello world" examples they include. Part of this is from attempting to conform to embedded-HAL traits, which support only the broadest feature sets.
I intend to have a try of both rust and tinygo.
Micropython is only ok on an esp32 with psram.
Ultimately, the embedded space (including all sorts of low-level, retro, "bare-metal", remote etc. programming) has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
There is a section called no-std crates which lists a couple of useful crates like bbqueue and heapless. I find it insightful to browse through the public repos of the authors of popular embedded rust crates and see what crates they use most often.
If you are working in an embedded environment Rust is still very capable, but the tooling for Rust does not seem at the level of the embedded tooling for C and C++.
You can still use Rust for embedded, and there are success stories to be found in the links below.
[1] https://www.rust-lang.org/what/embedded [2] https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart
I do think eventually it could replace C though -- because rust with `unsafe` blocks still has the possibility of being safer than C. This could be a boon to security critical software, as long as the performance margin isn't too hard. Shops that have found ways to write safe C will likely never move (they don't need to), but new ones might pick rust where they might have picked C otherwise.
BTW, the embedded support in rust is really impressive for such a young language: https://github.com/rust-embedded/awesome-embedded-rust
"the idea of putting "Embedded" on the front page and trying to advertise Rust as a useful embedded language isn't just laughable--it's dangerous. Rust is so far from useful in embedded that people who try to use it will NEVER come back"
Embedded is still at its early development stages, just like WASM and just like asynchronous network programming. Still, all those are on the front page.
WASM a year ago and wasm todays is a tremendous difference. A year ago, in my opinion, WASM was something for experimentation. Now, a lot of the ecosystem "just works" and is developing really quickly. You can write a working JS library and upload it to NPM without even touching a line of JavaScript code.
Async (network) programming in Rust with async/await is promising but still in flux, so the ecosystem hasn't settled yet. Still, a lot of systems already use it in production.
Embedded in Rust a year ago was mostly a list of blogposts, an early draft of HAL traits and some random register binding crates. You had to use nightly, and your code would frequently break. But in just a few weeks, you'll be able to use Embedded on stable, there is an active ecosystem developing around svd2rust, groups like stm-rs and lpc-rs are forming and a lot of device agnostic drivers have already been written. Combine that with a very promising preview of a new version of the RTFM framework. It's not production ready yet, but I'd estimate it will be within 2 years. See https://github.com/rust-embedded/awesome-embedded-rust for a summary of the ecosystem.
The problem with the post above is not that it's written in a strong tone. It's that it's uninformed, generalizing and unfair.
James Munn gave a super interesting talk at this year's RustConf about some of the abstractions they're building for embedded systems: https://www.youtube.com/watch?v=t99L3JHhLc0
I think Rust is in a great position to become incredibly useful in the embedded space.
First of all, most embedded development makes use of bare metal, where the libraries take the role of an OS, or they use a specialized OS from the hardware vendor.
Just using pure ANSI C isn't possible, because the standard does not expose the hardware features from the underlying platform, so the alternatives are to use Assembly, or language extensions.
Naturally language extensions are more convenient to use, so that is what most developers end up doing.
Also there are many types of embedded platforms, you can be targeting anything between a tiny PIC with 8KB FLASH RAM to a powerful multi-core ARMv8-A with 8GB.
So the toolchain must allow for customization of what actually gets linked into the final binary, and the runtime must be as thin as possible.
Then there this the drivers story, each vendor gives you their own SDK, which most of the time is the only way to access their devices.
It is typical for open source projects to reverse engineer some of those SDKs to get the necessary information for linker maps, compiler flags and driver information.
Regarding Rust, there is an ongoing effort to create a embedded library for hardware drivers, as means to write portable code.