-
Curious, I periodically make some effort to get a little more into this topic and then I usually get lost somewhere (mostly due to out of date introductory material and lack of documentation
).
I just stumbled upon this fresh new YouTube channel and I think he's really off on the right foot, if only for the lack of "uhmmm..."ing. The quality of both content and editing is really outstanding. Let's hope he can keep up with this.
(disclaimer, I have nothing to do with that guy)
Edit: for whatever reason the link was missing
https://www.youtube.com/@therustybits/videos -
imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out. In part this is due to the majority of development following a "perf supremacy" mentality, which fair enough is a valid tradeoff and SDKs in other languages make it, but the issue is that there is no "Arduino" or "CircuitPython" for Rust.
And like, is not like the current crates in the ecosystem are "bad", but a simple observation to make is that it became way easier to introduce people to embedded C when Arduino came out. In Rust it feels like you don't get anything under the difficulty level of learning to work with CMSIS-based SDKs which of course.
The current situation is that Rust is great to use If you already know some stuff about fw dev, but not so great to onboard someone into fw dev -
And realistically performance is not very critical for a large part of embedded software as a significant part of embedded software is dealing with interfacing to the outside world. Security is way more important. I foresee languages like Lua and (more likely) Python taking over in embedded programming.
-
imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out.
To be fair, try to find good-quality, easy-to-follow embedded training material which uses C - or any other language, for that matter. So even for a mature language which everyone uses, the good tutorials / documentation simply never comes, therefore it is unrealistic to expect Rust would do better here. -
imho the problem with embedded Rust adoption is the lack of good quality, easy-to-follow training material as you point out.
To be fair, try to find good-quality, easy-to-follow embedded training material which uses C - or any other language, for that matter. So even for a mature language which everyone uses, the good tutorials / documentation simply never comes, therefore it is unrealistic to expect Rust would do better here.
I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier. -
I think he's really off on the right foot
Good video editing, but damaging approach in my opinion. The channel has 2 videos so far. First, is a marketing pitch for the channel, it says nothing significant.
Second video installs the toolchain. Very diluted useful info, if any. Also, it doesn't make any sense unless you already know the subject, but then why watching a video about what you already know? Then, he reads from the monitor a lot, numbers and such. Certainly not my stile.
Then, he does the mistake of trying to be funny on an engineering teaching topic. That's a bad idea. Why everybody's trying to be a standup comedian?
The audience is not watching any 101 video for a laugh or for entertainment.
Another thing, don't use in a 101 class figurative words, interjections, emphasizing words and alike bloatware. It almost looks like the text was AI generated or something (it was probably not). And don't "sing" the words, don't put emotional content in voice, don't make faces to the camera, don't add background music. In general, don't go for emotional engaging while teaching tech content, because emotions are distracting. Can't have focus while distracted.
While the effort of making teaching videos is laudable, and the editing shows a lot of care, that's not the kind of videos I would watch.
Though, for a first 2 videos, it looks like a promising channel.
-
I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.
I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.
Edit: misunderstood, I fully agree when explained by JPortici. -
I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.
I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.
i think he meant a compiler/crate/whatever sponsored by the manufacturers instead of having part support added by random people that may remove it in the future if they don't bother keeping on with language/toolchain changes
in which case i agree completely: I'm not going to consider rust for my embedded projects if my target MCU are not supported, and i'm very unlikely to use experimental toolchains in commercial products -
I'd argue lack of decent cross platform tools (from vendors ideally) is a bigger barrier.
I disagree. Ridiculous amounts of work has gone into developing better and better embedded cross platform frameworks. Yet there is never success, they are either difficult and hard to use, or simple but too compromised. And there are too many, and they are short-lived, so now you have to learn an extra skill and still get nowhere. Generic hardware abstraction with the usual MCU requirements simply is an unsolvable problem. We would be better off by stopping this timesink. If the same amount of time would have been spent on documentation and tutorials, and just writing code to get more used to writing code, we would be far better off.
i think he meant a compiler/crate/whatever sponsored by the manufacturers instead of having part support added by random people that may remove it in the future if they don't bother keeping on with language/toolchain changes
in which case i agree completely: I'm not going to consider rust for my embedded projects if my target MCU are not supported, and i'm very unlikely to use experimental toolchains in commercial products
Yeah, gimme the Rust in CubeIDE or whatever with good support and I'll learn it! By cross-platform, I mean I can run it on Windows/Linux/Mac, all 3 of which I use. -
Maybe relevant? Rust for Embedded Systems: Current State, Challenges and Open Problems
JW
PS. Those videos... are IMO boring in an interesting way. -
Allow me to take Rust as the critique of the C based embedded frameworks. If I would move away/start again, my choice is Swift:
https://madmachineio.github.io/SwiftIO/documentation/swiftio/
Hardware is either their own or RP2040:
https://madmachine.io/collections/frontpage
A good example of documentation/learning guide: https://docs.madmachine.io/learn/peripherals/speaker -
Side note, Rust got some traction recently, might be used in the future for the Linux kernel, too.
AFAIK, the Linux kernel was using only C, it was a total surprise to hear about Rust in the Linux kernel. Not sure if that was only an attempt idea, or if it was put in practice already.
-
AFAIK, the Linux kernel was using only C,
Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/Quoteit was a total surprise to hear about Rust in the Linux kernel. Not sure if that was only an attempt idea, or if it was put in practice already.
Nothing will be rewritten. There are advanced hooks in place to allow new Rust code to interact with existing kernel code, e.g. new device drivers could be written in Rust. There are still a few wrinkles, but they can be overcome in time.
Summary: there will be Rust modules loaded into the kernel. -
But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.AFAIK, the Linux kernel was using only C,
Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/
Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.
So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).
-
But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.AFAIK, the Linux kernel was using only C,
Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/
Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.
So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).
Half a loaf is better than no bread.
Just because we can't stop bad drivers, it doesn't mean we shouldn't require seatbelts.
And time will tell; it is early days. -
But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.AFAIK, the Linux kernel was using only C,
Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/
Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.
So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).
This feels like the same argument in cyclist circles some years ago when disc brakes were still a debate. Some people insisted that you break the same, that discs weight more, etc etc etc. But nothing really beats how consistent, reliable and powerful they are regardless of weather conditions.
I can ride most routes on a disc brake and a v-brake bike, but a big descent on a rainy day with v-brakes? that would scare the shit out of me.
Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence. -
The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?
But tell me how Rust is any better as Rust also supports unsafe programming. And if you look at examples you'll see that you can't really use Rust without unsafe programming. So how is Rust going to stop programmers from cutting corners? It is no better than C or C++ in that respect.AFAIK, the Linux kernel was using only C,
Torvalds famously has strong (and IMNSHO sane) opinions about C++. https://lwn.net/Articles/249460/
Next thing we'll see is a whole lot of stuff in the Linux kernel using unsafe Rust because A) they can't make it work with safe Rust and B) the programmers think they are like Evil Knievel and keep doing the same coding stunts like you can find in the current Linux kernels. Meanwhile the Linux kernel would have gotten so much better both in code quality and performance when they would have rewritten it in C++.
So far Rust looks like a solution looking for a problem to me. It doesn't bring a new solution to an existing problem. Ada (which is highly regarded as a safe language) has been around for a long time and never gained mainstream traction because it needs a rather elaborate runtime (just like Rust if you read carefully enough).
This feels like the same argument in cyclist circles some years ago when disc brakes were still a debate. Some people insisted that you break the same, that discs weight more, etc etc etc. But nothing really beats how consistent, reliable and powerful they are regardless of weather conditions.
I can ride most routes on a disc brake and a v-brake bike, but a big descent on a rainy day with v-brakes? that would scare the shit out of me.
Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence.
-
The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?
I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++
I can see Rust being used to implement the libraries used to data crunching in higher level languages(polars for example), but not as the data cruncher language itself. Test automation eventually, websites and desktop applications is kind of a tricky situation - It's already being used for web servers and it's essentially the dominant language that compiles to wasm, but the front end will keep being dominated by the ECMAScript overlords
-
You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?
I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++ -
to add some info to the thread, some links to projects/vendors already giving some Rust support apart from Linux
Espressif: https://mabez.dev/blog/posts/esp-rust-24-01-2024/ (Scott Mabin is a direct employee)
WindRiver: https://harmonicss.co.uk/vxworks/using-rust-with-vxworks-7/
Infineon: https://www.infineon.com/cms/en/product/promopages/rust/
Including the language in Zephyr seems to be under discussion.
-
Rust is like the disc brakes.
Or at least you think it is...QuoteYou get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust.
Simplicity and ease of development are quite fresh arguments indeed - what we are used to hear are claims of roughly same complexity code resulting in some extra safety, and it is quite easy to understand why Rust could, at least theoretically, fulfill this claim.
But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind? -
You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimized but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.
I highly doubt that interpreted code running on an embedded virtual machine is going to be faster than say some compiled Rust glue code. Like I can give the benefit of the doubt, perhaps you have some receipts for that claim that I can take a look at? Legit interested.
The one thing that for sure is not better is required space to run the same code. In some platforms space might be irrelevant, but some of us still work with less than a MB of space for code and RAM. Being able to do complex stuff without breaking easy without breaking the memory budget is a nice advantage -
But traditionally complex problems becoming a breeze? This sounds like a marketing speech for AI or something; now such extraordinary claim would most definitely require extraordinary evidence, like a demonstration of a problem which takes days to solve in C, maybe hundreds (thousands?) of lines of code, and which Rust solves in no time. Any example in mind?
Fair criticism. I don't have another receipt apart from personal experience, I used the term "breeze" because that's how it felt being able to do significant changes in a project with confidence when I was using Rust. At a professional level I work with C and usually the roadblocks I find or the stuff that causes the most time wasting is usually something preventable by Rust, all warnings turned on and all. Could be a nice experiment to benchmark oneself trying to implement some complex project in one language an another with all top level design work done from the start -
Ferrous Systems does some good training workshops on rust in general and embedded specifically. The paid workshops can be a little pricey, but they also post most of the training materials on their GitHub: https://github.com/ferrous-systems
-
You might be unpleasantly surprised. What Lua and Python are doing is binding building blocks, written in lower level languages, together in a way that the programmer doesn't really need to bother with pointers and memory allocation (and hence resulting in more robust code). Often the building blocks are highly optimised but still easy to unit-test for flaws. So the end result can be faster compared to writing code yourself in Ada, C, C++ or Rust.The latter can be done in Lua or (micro)Python in the same way. On top of that Lua and even more so, Python are existing languages with a very low threshold to get started with and a very broad field of applications. IOW: do you see Rust ever becoming a programming language for websites, desktop applications, test automation or data crunching?
I mean, Lua and micropython are not even in the same perf neighborhood. Rust is a explicitly designed for Systems Programming, essentially equal perf neighborhood as C and C++
Your arguing that C is a special case does not stand up to scrutiny.
A much more reasonable position was given thus:...
Rust is like the disc brakes. You get done the same work you do in C in unsafe, but more complex, intricate stuff that would have you second guessing yourself in C for days it's a breeze in Rust. The value in Rust is not in doing the stuff that will always be unsafe like directly writing to peripheral registers, the power of Rust is in making it easier to implement the complex stuff with confidence.
That's why we have circuit theory to hide EM fields.
That's why we have analogue circuits to hide circuit theory.
That's why we have digital logic gates to hide analogue circuits.
That's why we have RTLs to hide digital logic gates.
That's why we have microcode to hide RTLs.
That's why we have assembler code to hide microcode.
That's why we have C and other languages to hide assembler code.
That's why we have higher level languages to hide ....
C is just one language and abstraction in a continuum.
C is not a particularly good abstraction, since too many lower levels leak through, e.g. aliases, volatile, memory models, parallel processes, interrupts.
We need better.
Better languages and abstractions are already here, but they are not evenly distributed.