10 ms·

Something is weirdly rotten in the Rust embedded ecosystem. The overarching experience is best described as akin to C++ template metaprogramming. The final resu

Something is weirdly rotten in the Rust embedded ecosystem. The overarching experience is best described as akin to C++ template metaprogramming. The final result is that setting a GPIO output somehow requires unwrapping an option, as if we didn't just set a single bit in some register and there were actual meaningful errors with that operation the uC could detect.

the__alchemist 5y ago
Typestates and reliance on `embedded-hal` traits are a particular pain. I think we're in a weird spot, where the language itself, and some of the build tools (Like those by the Knurling team) are outstanding, but the most popular libraries have made questionable design decisions, and have flaws that show almost immediately. I'm curious how many teams are developing new projects using Rust, but staying away from the open source ecosystem.
- codeflo 5y ago
  It’s not just crates.io. I have a minimal, no Libc, no runtime dependencies Windows project for fun that compiles to a tiny executable of only a few kilobytes. If you’re going down this minimalist/better C route, you increasingly have to avoid large parts of the Core library as well, which is becoming more bloated by the minute. The culture seems to move in the direction of “avoid unsafe at all costs” (even where that makes the API so complicated that it hurts correctness in practice) and “avoid dynamic dispatch at all costs” (even where that hurts performance).
- vbsteven 5y ago
  Your comment made me wonder if crates.io is starting to show some of the same issues that npm has. Lots of small packages, not always consistent, focussed on one use case that make other use cases non-optimal. The recent posts about Rust in Android shows a side of this. They are avoiding Cargo in favor of plugging in their own build system. Use the language for its benefits and avoid the ecosystem (partly).
  - rcxdude 5y ago
    I think the case with embedded code on crates.io is more along the opposite: they're trying to make the experience as consistent as possible by defining common interfaces for embedded drivers so code can run consistently with different hardware or libraries. The problem is it's really hard to design such abstractions, especially safely, when you can't make many assumptions about the hardware it'll be abstracting over and efficiency is paramount.
the__alchemist 5y ago
To address unwrapping the GPIO set: this is caused by a (popular) misuse of embedded-hal traits. The traits are fallible to be general, but HALs use this as their primary API, and make it always pass. So unwrap is effectively clutter, and misdirection. The answer is to provide a primary API that's decoupled from the traits, and bolt on the traits to support generic drivers.

the__alchemist 5y ago

Typestates and reliance on `embedded-hal` traits are a particular pain. I think we're in a weird spot, where the language itself, and some of the build tools (Like those by the Knurling team) are outstanding, but the most popular libraries have made questionable design decisions, and have flaws that show almost immediately. I'm curious how many teams are developing new projects using Rust, but staying away from the open source ecosystem.

codeflo 5y ago
It’s not just crates.io. I have a minimal, no Libc, no runtime dependencies Windows project for fun that compiles to a tiny executable of only a few kilobytes. If you’re going down this minimalist/better C route, you increasingly have to avoid large parts of the Core library as well, which is becoming more bloated by the minute. The culture seems to move in the direction of “avoid unsafe at all costs” (even where that makes the API so complicated that it hurts correctness in practice) and “avoid dynamic dispatch at all costs” (even where that hurts performance).
vbsteven 5y ago
Your comment made me wonder if crates.io is starting to show some of the same issues that npm has. Lots of small packages, not always consistent, focussed on one use case that make other use cases non-optimal. The recent posts about Rust in Android shows a side of this. They are avoiding Cargo in favor of plugging in their own build system. Use the language for its benefits and avoid the ecosystem (partly).
- rcxdude 5y ago
  I think the case with embedded code on crates.io is more along the opposite: they're trying to make the experience as consistent as possible by defining common interfaces for embedded drivers so code can run consistently with different hardware or libraries. The problem is it's really hard to design such abstractions, especially safely, when you can't make many assumptions about the hardware it'll be abstracting over and efficiency is paramount.

the__alchemist 5y ago

To address unwrapping the GPIO set: this is caused by a (popular) misuse of embedded-hal traits. The traits are fallible to be general, but HALs use this as their primary API, and make it always pass. So unwrap is effectively clutter, and misdirection. The answer is to provide a primary API that's decoupled from the traits, and bolt on the traits to support generic drivers.