5 ms·

I 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

I 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."

OtomotO 5y ago
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.
zibzab 5y ago
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.
- CodesInChaos 5y ago
  > 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)
  - eldruin 5y ago
    It depends on your target architecture. For example, embedded development on ARM with stable Rust has been possible since 2018 (Rust 1.31)
- Lorkki 5y ago
  > We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.
  - capitol_ 5y ago
    It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219 https://github.com/cortex/ripasso/issues/219
    - eldruin 5y ago
      This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
      - zibzab 5y ago
        A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago. A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.
        couchand 5y ago
        Depends on the architecture: ARM for instance is a tier 1 target and you can use stable.
        steveklabnik 5y ago
        This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)
Unklejoe 5y ago
> I need my code to build/run today and also in 10 years I think you should stick with C if this is a hard goal. Let Rust settle for some years before going all in.

OtomotO 5y ago

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.

zibzab 5y ago

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.

CodesInChaos 5y ago
> 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)
- eldruin 5y ago
  It depends on your target architecture. For example, embedded development on ARM with stable Rust has been possible since 2018 (Rust 1.31)
Lorkki 5y ago
> We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.
- capitol_ 5y ago
  It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219 https://github.com/cortex/ripasso/issues/219
  - eldruin 5y ago
    This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code. See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
    - zibzab 5y ago
      A lot of embedded stuff needs nightly. Or at least, it was like this a year or two ago. A related issue is that for many companies "stable" means the version shipped with Ubuntu LTS.
      - couchand 5y ago
        Depends on the architecture: ARM for instance is a tier 1 target and you can use stable.
        steveklabnik 5y ago
        This is true for aarch64, but if you're not doing an embedded-linux style project, it's very likely you'll need nightly for inline assembly, though a significant chunk of that is being stabilized as we speak (though sadly not yet enough for my work...)

Unklejoe 5y ago

> I need my code to build/run today and also in 10 years I think you should stick with C if this is a hard goal. Let Rust settle for some years before going all in.