7 ms·

Rust is a brilliant candidate for embedded systems - safety, built-in package management, it's ergonomic and pleasant to work with. But it has one fundamental p

Rust is a brilliant candidate for embedded systems - safety, built-in package management, it's ergonomic and pleasant to work with. But it has one fundamental problem, which the entire community refuses to address: the steep entry. Several months ago I was making a wedding gift for a friend which almost exclusively involved embedded development. And having several brand new STM32's laying around I initially opted for them and rust. In all fairness the entire thing did not involve all that much: If I recall correctly, an I2C display, RTC, sound sensor, some adafruit soundboard, sound amplifier+speaker and a couple of push buttons. I went against one of my own core philosophies of not using something for the sake of using it, that being rust on this occasion. In theory the STM32 should be a great candidate since the Embedded Rust Book revolves around it. Well... No. You see, each time you decide to get something rolling, you have to work your way through tons of configuration, completely blind. And just as you are convinced that you did everything right, compile your code and flash the device, you get a cryptic error and you are left clueless as to what it may be. It took me 7 days to get the I2C display going. I guess you could slash a few hours since I had to get Cyrillic letters out on the screen but that was just a few hours at best. At one point I simply gave up because I didn't have that much time to waste and ran back to the trusty Arduino. And this is fundamentally what's crippling the embedded Rust world - it's way too much of a hassle to be considered a good option when you have to deal with a schedule - you have to spend absurd amounts of time fiddling with setup and poor documentation. If those issues are addressed at one point, I'd gladly ditch arduino for good. But until then the embedded rust is just some fun toy to play around with on a day off.

sanjayio 5y ago
I’m curious how well you knew Rust prior to starting? I’m learning Rust at a very slow pace. I finished a language specific course, going through advent, and I’m planning on going through an embedded Rust book next. I can imagine attempting to jump straight into embedded Rust could be very challenging.
- brundolf 5y ago
  I get the sense they weren't talking about what most people mean when they say "steep entry" in a Rust context (i.e. the language itself), but specifically its support and documentation for the embedded case
- axegon_ 5y ago
  Rust has been my goto language for several years for multiple projects, was a primary language at a certain point not too long ago for what it's worth. Generally depends on your background. Rust in general suffers from one... I guess you can call it disease: evangelists. Many people are convinced that it is the best language for any purpose and you'll never need anything else(something which can be seen in the js and java community and we know the outcome of that). To quote a guy I used to work with: "The perfect web stack is actix + rust wasm. You can't possibly need anything else". Uuugh... Yeah... Sorry, no. It's definitely a language you can't learn overnight so don't overdo it - it takes time to wrap your head around many of the concepts. While I admit I am a fanboy, I also openly admit that it's not suitable for every purpose. Most certainly not for web development - yes it is fast, yes actix can boost some astonishing benchmarks but truth is it hardly pays off to put in so much effort, especially when you are working on a schedule. It's a question of trade-offs. People address many async-await logical blocks by slapping Arc<RwLock<T>> or Arc<Mutex<T>> everywhere and a ton of read and write locks to get around it. Which if perfectly acceptable if you don't overdo it. Otherwise you will have to spend endless hours trying to catch some lock somewhere which is biting your head. Hence the reason why I'd really avoid it for large and complex web services for instance. There are other areas where it's perfect. Three personal projects I'm working on(which I'll hopefully get to open source over the next 6-8 months) and where I don't regret picking rust: * Raspberry-pi powered CNC router(though dealing with gcode is a huge pain in the ass). * Distributed full-text search engine(similar to elasticsearch). * Automated image pulling from NOAA satellites with an SDR dongle(though in this particular instance I'm taking a shortcut by piggybacking on librtlsdr). As far as embedded rust. First is what I mentioned earlier - setting up a development environment is an absolute hell, and far not only the first time. You have to go through the same steps each time. At this point I'm somewhat used to it and I can unpack an embedded board and get it going in say 20-30 minutes(having the spec sheet at bay is a must). It also takes an additional layer of tweaking your brain: it takes some time to get used to things such as #![deny(unsafe_code)], #![no_main], #![no_std] and #[entry]. It's nothing like arduinos if you've worked with those, where you plug in the board, open the arduino IDE, select the board model and port and hit "upload".
  - greesil 5y ago
    My experience with getting started with any embedded system, even if I am programming in C, is that it will have a steep learning curve unless someone in the community already went through this and published a how-to.
- FpUser 5y ago
  I jumped into embedded C and had working firmware in a couple of days. Of course I knew C but I am no expert and there was like 10 years since I've used it last time and that last time was not a firmware.
deleted 5y ago
[deleted]
seoaeu 5y ago
> But it has one fundamental problem, which the entire community refuses to address: the steep entry. Do you have any evidence for this? From what I’ve seen, the Rust community has invested considerably in creating learning resources and so forth to make getting started easier. However there’s only a finite amount of time/people working on it, so rough edges remain for less common use cases
- dataangel 5y ago
  Rust doesn't have a volatile memcpy yet, bitfield ergonomics are poor, global variables require thread safety even when targeting a single core device, the memory model isn't finished, and upholding the rules the compiler expects you to respect in unsafe code with regard to aliasing is difficult to wrap your head around (pointer provenance, even the author of tokio got it wrong).
- axegon_ 5y ago
  Two major ones: first one is the obvious - I don't see a whole lot of effort to make the first steps easier. Second one is I brought this topic on several occasions in the rust community, the closes I got to a sensible(note the word closest) answer was "well you could package development environments for different hardware inside docker containers". Which for better or worse gives all the credibility one might want to this[1] comment. [1] https://news.ycombinator.com/item?id=29619566 https://news.ycombinator.com/item?id=29619566

sanjayio 5y ago

I’m curious how well you knew Rust prior to starting? I’m learning Rust at a very slow pace. I finished a language specific course, going through advent, and I’m planning on going through an embedded Rust book next. I can imagine attempting to jump straight into embedded Rust could be very challenging.

brundolf 5y ago
I get the sense they weren't talking about what most people mean when they say "steep entry" in a Rust context (i.e. the language itself), but specifically its support and documentation for the embedded case
axegon_ 5y ago
Rust has been my goto language for several years for multiple projects, was a primary language at a certain point not too long ago for what it's worth. Generally depends on your background. Rust in general suffers from one... I guess you can call it disease: evangelists. Many people are convinced that it is the best language for any purpose and you'll never need anything else(something which can be seen in the js and java community and we know the outcome of that). To quote a guy I used to work with: "The perfect web stack is actix + rust wasm. You can't possibly need anything else". Uuugh... Yeah... Sorry, no. It's definitely a language you can't learn overnight so don't overdo it - it takes time to wrap your head around many of the concepts. While I admit I am a fanboy, I also openly admit that it's not suitable for every purpose. Most certainly not for web development - yes it is fast, yes actix can boost some astonishing benchmarks but truth is it hardly pays off to put in so much effort, especially when you are working on a schedule. It's a question of trade-offs. People address many async-await logical blocks by slapping Arc<RwLock<T>> or Arc<Mutex<T>> everywhere and a ton of read and write locks to get around it. Which if perfectly acceptable if you don't overdo it. Otherwise you will have to spend endless hours trying to catch some lock somewhere which is biting your head. Hence the reason why I'd really avoid it for large and complex web services for instance. There are other areas where it's perfect. Three personal projects I'm working on(which I'll hopefully get to open source over the next 6-8 months) and where I don't regret picking rust: * Raspberry-pi powered CNC router(though dealing with gcode is a huge pain in the ass). * Distributed full-text search engine(similar to elasticsearch). * Automated image pulling from NOAA satellites with an SDR dongle(though in this particular instance I'm taking a shortcut by piggybacking on librtlsdr). As far as embedded rust. First is what I mentioned earlier - setting up a development environment is an absolute hell, and far not only the first time. You have to go through the same steps each time. At this point I'm somewhat used to it and I can unpack an embedded board and get it going in say 20-30 minutes(having the spec sheet at bay is a must). It also takes an additional layer of tweaking your brain: it takes some time to get used to things such as #![deny(unsafe_code)], #![no_main], #![no_std] and #[entry]. It's nothing like arduinos if you've worked with those, where you plug in the board, open the arduino IDE, select the board model and port and hit "upload".
- greesil 5y ago
  My experience with getting started with any embedded system, even if I am programming in C, is that it will have a steep learning curve unless someone in the community already went through this and published a how-to.
FpUser 5y ago
I jumped into embedded C and had working firmware in a couple of days. Of course I knew C but I am no expert and there was like 10 years since I've used it last time and that last time was not a firmware.

deleted 5y ago

[deleted]

seoaeu 5y ago

> But it has one fundamental problem, which the entire community refuses to address: the steep entry. Do you have any evidence for this? From what I’ve seen, the Rust community has invested considerably in creating learning resources and so forth to make getting started easier. However there’s only a finite amount of time/people working on it, so rough edges remain for less common use cases

dataangel 5y ago
Rust doesn't have a volatile memcpy yet, bitfield ergonomics are poor, global variables require thread safety even when targeting a single core device, the memory model isn't finished, and upholding the rules the compiler expects you to respect in unsafe code with regard to aliasing is difficult to wrap your head around (pointer provenance, even the author of tokio got it wrong).
axegon_ 5y ago
Two major ones: first one is the obvious - I don't see a whole lot of effort to make the first steps easier. Second one is I brought this topic on several occasions in the rust community, the closes I got to a sensible(note the word closest) answer was "well you could package development environments for different hardware inside docker containers". Which for better or worse gives all the credibility one might want to this[1] comment. [1] https://news.ycombinator.com/item?id=29619566 https://news.ycombinator.com/item?id=29619566