5 ms·

Glad to C doing so well at what it's best at - efficiency and size. I worked in embedded space for years. Rust does not suit that environment. Different tools

Glad to C doing so well at what it's best at - efficiency and size. I worked in embedded space for years. Rust does not suit that environment. Different tools for different needs! I appreciate this, as looking for better tools in embedded space is welcome. Just pity that so many of them come with so many dependencies and large library sizes.

morning-coffee 3y ago
> I worked in embedded space for years. Rust does not suit that environment. It seems to be getting better though. For example... https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
AlotOfReading 3y ago
Honestly, Rust is a lot closer to ready in the embedded space than you probably think. It's perfectly adequate to replace most of the embedded C++ out there today and coexist with the remaining C.
- uxp100 3y ago
  I kept hearing rust was ready for embedded pretty early on (like 2018), and I fooled with it for a bit in 2021 and it definitely was not, on the platform I chose at least. Updating compiler version (minor update) broke existing code, I was relying on one guys hobby to support the relatively popular (though fading) mcu I pulled out of my parts bin. What about rust today makes it suitable for replacing some code but not all of it? What’s better, what still isn’t there yet? I guess from my limited experience register fiddling ergonomics in rust were miserable, but I was blessed with working with an extremely safe and ergonomic set of c macros at work (you could do something like rmw(i2s, clockconfig, enable, set) and know if it compiled that such a value corresponded to a valid value in a field that existed in such a register in such a peripheral) and I know some vendors provided c “pac” equivalents that were pretty sloppy and error prone, if still nicer than all the punctuation needed to set a bit in a register in rust. How is HAL quality for popular platforms? How much does that matter? The stm provided c HAL is extremely limiting in my experience, anything fancy requires bypassing it, and I worked places without touching the vendor provided libraries ever but I guess having it as an option for popular platforms is important.
  - Yoric 3y ago
    For what it's worth, there's bare metal Rust in orbit right now (https://www.gamaspace.com/ https://www.gamaspace.com/). We'll see how that goes, but I'd like to see it work!
  - estebank 3y ago
    > Updating compiler version (minor update) broke existing code Could you elaborate on that? That's not something that's supposed to happen and if it has, I would like to make sure we register it in our issue tracker.
    - deciduously 3y ago
      Wow, you really are vigilant and omnipresent. Thank you for the DX!
    - uxp100 3y ago
      I don't really remember, its approaching 3 years now, but the target was msp430-none-elf, and some function I had to implement had its signature change? abort! i guess? I don't think it was accidental or unknown, I think i found some conversation on a mailing list when I went to look for it.
      - AlotOfReading 3y ago
        Panic changed quite a bit in no_std around 2018 [0], perhaps that's what you're remembering? You could only see that issue on nightly though, and at that point no_std / embedded rust was very much a work in progress that was limited to nightly no matter what random people were saying. [0] https://users.rust-lang.org/t/psa-breaking-change-panic-fmt-language-item-removed-in-favor-of-panic-implementation/17875 https://users.rust-lang.org/t/psa-breaking-change-panic-fmt-...
        uxp100 3y ago
        I think this was the issue, but it wasn’t 2018 when it I ran into it (looking at some notes it seems like 2020, not 2021). Perhaps it was slow to propagate to the tier 3 supported toolchain I was using? Somehow I got an old version? Idk, it was something I spent a few hours on years ago. I was on nightly, I had to be for msp430 iirc.
Voultapher 3y ago
There are many situations where C libraries are amazingly small. This however is not one of those cases. ipnsort is aggressively optimized for binary-size. A sort instantiation for u64 is ~4.5k while crumsort was ~53k last time I measured. I know several easy ways to boost ipnsort's performance by 10% but don't because they don't align with my binary-size and compile-time goals.
m00x 3y ago
It actually does. You can modify Rust to run without stdlib, reducing its size significantly. There are also tons of tricks to make this work really well so it's very close to C performance. https://esp-rs.github.io/book/ https://esp-rs.github.io/book/ https://github.com/avr-rust/ruduino https://github.com/avr-rust/ruduino
- saagarjha 3y ago
  C of course generally does not require as many of these tricks, which is why people reach for it first.
  - m00x 3y ago
    C also has decades of maturity behind it. Rust will get there.
  - rstuart4133 3y ago
    It's not much of a trick in the case of Rust. Rust has a "std" library that I guess is the equivalent of "libc", but is far more comprehensive. Rust also has a "core" library which is the absolute minimum the compiler assumes. It's well defined, well documented and how you use it is standardised. All C implementations have a similar library. For gcc you get it with -lgcc. But it is not "well defined, well documented, with standardised usage". So I'd disagree with you. I've done it, and avoiding libc for in different C implementations is tricker than Rust.
the__alchemist 3y ago
I consider embedded to be a core competency of Rust. It's one of a few languages that can run on these devices, and compared to the others, is a nicer experience. The language itself, the tooling, and the compile/flash/debug process make it appealing this domain. Support outside of ARM is a bit rough, but it's improving for RISC-V and Espressif.

morning-coffee 3y ago

> I worked in embedded space for years. Rust does not suit that environment. It seems to be getting better though. For example... https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown

AlotOfReading 3y ago

Honestly, Rust is a lot closer to ready in the embedded space than you probably think. It's perfectly adequate to replace most of the embedded C++ out there today and coexist with the remaining C.

uxp100 3y ago
I kept hearing rust was ready for embedded pretty early on (like 2018), and I fooled with it for a bit in 2021 and it definitely was not, on the platform I chose at least. Updating compiler version (minor update) broke existing code, I was relying on one guys hobby to support the relatively popular (though fading) mcu I pulled out of my parts bin. What about rust today makes it suitable for replacing some code but not all of it? What’s better, what still isn’t there yet? I guess from my limited experience register fiddling ergonomics in rust were miserable, but I was blessed with working with an extremely safe and ergonomic set of c macros at work (you could do something like rmw(i2s, clockconfig, enable, set) and know if it compiled that such a value corresponded to a valid value in a field that existed in such a register in such a peripheral) and I know some vendors provided c “pac” equivalents that were pretty sloppy and error prone, if still nicer than all the punctuation needed to set a bit in a register in rust. How is HAL quality for popular platforms? How much does that matter? The stm provided c HAL is extremely limiting in my experience, anything fancy requires bypassing it, and I worked places without touching the vendor provided libraries ever but I guess having it as an option for popular platforms is important.
- Yoric 3y ago
  For what it's worth, there's bare metal Rust in orbit right now (https://www.gamaspace.com/ https://www.gamaspace.com/). We'll see how that goes, but I'd like to see it work!
- estebank 3y ago
  > Updating compiler version (minor update) broke existing code Could you elaborate on that? That's not something that's supposed to happen and if it has, I would like to make sure we register it in our issue tracker.
  - deciduously 3y ago
    Wow, you really are vigilant and omnipresent. Thank you for the DX!
  - uxp100 3y ago
    I don't really remember, its approaching 3 years now, but the target was msp430-none-elf, and some function I had to implement had its signature change? abort! i guess? I don't think it was accidental or unknown, I think i found some conversation on a mailing list when I went to look for it.
    - AlotOfReading 3y ago
      Panic changed quite a bit in no_std around 2018 [0], perhaps that's what you're remembering? You could only see that issue on nightly though, and at that point no_std / embedded rust was very much a work in progress that was limited to nightly no matter what random people were saying. [0] https://users.rust-lang.org/t/psa-breaking-change-panic-fmt-language-item-removed-in-favor-of-panic-implementation/17875 https://users.rust-lang.org/t/psa-breaking-change-panic-fmt-...
      - uxp100 3y ago
        I think this was the issue, but it wasn’t 2018 when it I ran into it (looking at some notes it seems like 2020, not 2021). Perhaps it was slow to propagate to the tier 3 supported toolchain I was using? Somehow I got an old version? Idk, it was something I spent a few hours on years ago. I was on nightly, I had to be for msp430 iirc.

Voultapher 3y ago

There are many situations where C libraries are amazingly small. This however is not one of those cases. ipnsort is aggressively optimized for binary-size. A sort instantiation for u64 is ~4.5k while crumsort was ~53k last time I measured. I know several easy ways to boost ipnsort's performance by 10% but don't because they don't align with my binary-size and compile-time goals.

m00x 3y ago

It actually does. You can modify Rust to run without stdlib, reducing its size significantly. There are also tons of tricks to make this work really well so it's very close to C performance. https://esp-rs.github.io/book/ https://esp-rs.github.io/book/ https://github.com/avr-rust/ruduino https://github.com/avr-rust/ruduino

saagarjha 3y ago
C of course generally does not require as many of these tricks, which is why people reach for it first.
- m00x 3y ago
  C also has decades of maturity behind it. Rust will get there.
- rstuart4133 3y ago
  It's not much of a trick in the case of Rust. Rust has a "std" library that I guess is the equivalent of "libc", but is far more comprehensive. Rust also has a "core" library which is the absolute minimum the compiler assumes. It's well defined, well documented and how you use it is standardised. All C implementations have a similar library. For gcc you get it with -lgcc. But it is not "well defined, well documented, with standardised usage". So I'd disagree with you. I've done it, and avoiding libc for in different C implementations is tricker than Rust.

the__alchemist 3y ago

I consider embedded to be a core competency of Rust. It's one of a few languages that can run on these devices, and compared to the others, is a nicer experience. The language itself, the tooling, and the compile/flash/debug process make it appealing this domain. Support outside of ARM is a bit rough, but it's improving for RISC-V and Espressif.