This Year in Embedded Rust
blog.rust-embedded.org
This Year in Embedded Rust
1–10 of 64 posts
Re: This Year in Embedded Rust
#2It's great to see a community forming and the general enthusiasm.
But are there any vendors actively participating in or supporting Embedded Rust?
For example is any vendor porting drivers to native Rust?
Re: This Year in Embedded Rust
#3I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that.
I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."
Re: This Year in Embedded Rust
#4Two things have kept me away from embedded Rust before
1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean.
2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding.
I can see myself using Rust instead of C in more projects, but maybe first after things calm down a bit. I want my development environment outdated and boring, a.k.a. "stable".
Re: This Year in Embedded Rust
#5I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."
For me, even in high level, an API should only be broken, when/if it gives a benefit over the old approach.
Sadly quite often it's only new and shiny to sell something :/
I assume in embedded this is simply different, because the needs are others.
Re: This Year in Embedded Rust
#6I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."
If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase.
Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
Re: This Year in Embedded Rust
#7One of the things I really find limiting in Rust compared to C/C++ is conditional compilation, i.e. for different architectures: yes, the C/C++ pre-processor does suck in many ways and is masochistic if you're not careful, but it's also incredibly flexible.
Conditional compilation in Rust can be done per module, so in theory you can have different archs in different .rs files, each imported conditionally, but that then seems to mean duplication of things like structs, method/function signatures in different implementations, which is pretty annoying in many cases (i.e. you'd just want the inner bits of functions to be different, or optionally call certain subsets for certain archs). You can abstract some of this to 'common' modules to a limited degree, but not much in my experience, and that comes with additional 'plumbing' complexity anyway.
Rust has cfg attributes, and the cfg_if crate which in theory is a bit closer to the pre-processor functionality (and to a degree allows nesting/cascading like in C/C++), but in my experience these are just as annoying and limiting but in different ways: it's a macro, which is annoying in other ways (needs braces, has some issues with formatting, etc).
cfgs also seem to be exclusive, so I've found it incredibly messy getting a balance right between code re-use for common parts (i.e. function/method signatures) which need to be shared by multiple cfgs, and duplication.
Maybe I'm missing something?
Re: This Year in Embedded Rust
#8It's great to see a community forming and the general enthusiasm. But are there any vendors actively participating in or supporting Embedded Rust? For example is any vendor porting drivers to native Rust?
Espressif (the makers of the hugely popular ESP32/ESP8266/... microcontrollers) hired an embedded Rust community member to work full time on Rust support for their chips:
https://mabez.dev/blog/posts/esp-rust-espressif/
Re: This Year in Embedded Rust
#9One of the things I really find limiting in Rust compared to C/C++ is conditional compilation, i.e. for different architectures: yes, the C/C++ pre-processor does suck in many ways and is masochistic if you're not careful, but it's also incredibly flexible. Conditional compilation in Rust can be done per module, so in theory you can have different archs in different .rs files, each imported conditionally, but that th…
I just checked.
You can also add those same conditionals to functions and structs.
So you don't have to in- or exclude whole modules.
You can even use it in an if-statement, as seen in the example main function on the page I linked.
See here: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html
Re: This Year in Embedded Rust
#10I really hope embedded rust can become the next rock-solid foundation. I need my code to build/run today and also in 10 years. We have code in our codebase from at least the early 90s but I suspect it's older than that. I went into embedded because I really despise the code churn of higher level frameworks/languages. "We just released Qt5! Good luck rewriting your code."
If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
> We have already seen early Rust code not compiling with new compiler releases.
Are you talking about breaking changes in the compiler after Rust 1.0? That should be very rare, and generally easy to fix (e.g. by adding a few type annotations).
Or did you use unstable features? (Not sure if embedded is usable without unstable nowadays)