7 ms·

Is Rust preferable for the embedded systems engineer who is primarily concerned with being modern?

by ipnon 5y ago

maxk42 5y ago
Being modern for its own sake? I suppose it would be preferable, since Rust is newer and evolving rapidly. But if you're concerned with being employed and a wide variety of powerful tooling at your fingertips then C++ is probably a better bet. (Note: I am neither a C++ nor Rust developer, so I don't have a dog in this fight.)
adamnemecek 5y ago
Rust is always preferable.
- netr0ute 5y ago
  On what merits?
  - Inityx 5y ago
    Memory safety, build system, dependency management, the usual
    - adamnemecek 5y ago
      It's just overall productivity.
      - netr0ute 5y ago
        Can you define productivity?
        smoldesu 5y ago
        I can't speak for everyone, but I spent an unconscionable amount of time managing dependencies and libraries in C++. In Rust, it's the easiest part of my workflow.
        adamnemecek 5y ago
        You can speak for everyone. C++ dependency management is just...I don't even know where to begin.
        dkersten 5y ago
        > You can speak for everyone. Not really. I only use header-only libraries and dependency management is a breeze for me. I check each library out as a git submodule into a third-party subdirectory in my project directory, point the includes path at it and off I go. When I want to upgrade, I pull the git tag/branch/commit I want and recompile. Its pretty simple.
        adamnemecek 5y ago
        I mean that's cool but you are definitely working against the language as opposed to having the language support you. Also this works nicely for self contained dependencies, and much less nicely for not self contained dependencies.
        dkersten 5y ago
        > you are definitely working against the language How so? > Also this works nicely for self contained dependencies, and much less nicely for not self contained dependencies. Doesn't matter. You said: "You can speak for everyone." which is simply not true, as I have outlined. You didn't say anything about not self contained dependencies or whatnot. The person you replied to said "I spent an unconscionable amount of time managing dependencies and libraries in C++" and I... well, don't. So clearly not everybody does.
        5y ago
        pornel 5y ago
        For example, I almost never need to use a debugger or Valgrind with Rust. Mysterious memory corruption just isn't a thing. Memory leaks are not a problem either (even though technically Rust doesn't claim to prevent all leaks, it does well enough in practice). Rust catches data races, use of non-thread-safe functions, and use-after-free problems across the entire codebase, including (mis)use of 3rd party libraries, at compile time. I can add `.par_iter()` to a loop, and if it compiles, I know it doesn't mangle any data. If it doesn't compile, the compiler points me to the exact struct that needs a refcount, or a mutex, or atomic. That saves me weeks of chasing heisenbugs. In debug builds it checks all integer arithmetic for overflow (no need to wrap types in custom class, works for dependencies too). This has saved my ass a few times. There's a pretty decent standard library, and a good number of quality dependencies that can be installed with a 1-liner. If I need to (de)serialize a struct from JSON, it's a couple of lines. I want to switch that to msgpack instead, 2-line change. I need that compressed? 2 lines again, plugs in easily, and supports serialize-and-compress without an intermediate buffer. Build system uses convention over configuration, so there's no artisanal "build script" to manage, or even an argument which build system sucks less. Dependency management and workspaces work well enough that it's practical to modularize projects into smaller libraries, and actually reuse them. Unit testing is built-in. Doxygen-like generator is also built-in, no config needed. Of course any language can do the same, but having zero friction removes excuses and really helps making people actually use these things.
        adamnemecek 5y ago
        It's just such a step-up that it's not even comparable.
  - jimbob45 5y ago
    Is there anything C++ does better at this point? Outside of compatibility, that is.
- rvz 5y ago
  Too bad there is no first-class production ready GUI library for Rust that I can use for embedded systems. Qt and C++ it is then.
  - pjmlp 5y ago
    And on the context of Windows IoT, UWP is all about .NET and C++, with the Rust bindings pretty much still doing baby steps.
dmitrygr 5y ago
Why is "being modern" a concern? Luckily, embedded is not the web, where 5000 frameworks sprout over lunch. I've never heard of anyone in embedded caring about being modern. Only about solving the problems efficiently. So i am curious: why do you ask?
- ipnon 5y ago
  Embedded engineering seems to be a lost art in the America. The typical American programmer is certainly not an embedded engineer, and our industry and American universities focus mainly on the application layer of both practice and theory. My university's[a] computer architecture and operating systems courses are both taught entirely using simulation, either simulated hardware or virtual machines, and we would certainly never write our own bootloaders or really ever put code to the metal. It all seems more Shenzhen than Silicon Valley, like part of the stack is simply a bygone thing of the past for American software engineers. Neither C nor C++ could be considered new languages, and this seems to contribute to this estimation of embedded engineering as a "lost art." C and C++ give a "here be dragons feeling," that only the best engineers can hope to avoid pointer pitfalls and memory leaks. I wonder if Rust's advances in programming language theory could alleviate this problem. The new generation of programmers I feel I belong to are comfortable with functional programming, advanced types, and facile tooling like NPM. I have personally found embedded engineering underrated in American industry, both for fun and profit. If adopting modern practices leads to further embedded engineering adoption, that would be a worthwhile pursuit for individuals and our community. Perhaps this takes the form of Rust. [a] Top 300 in global ranking, with a standard but not cutting edge computer science program unlike Stanford or CMU. Having gone to only one university I admit this confusion could simply be a failing of my own education.
  - dmitrygr 5y ago
    Embedded has always been a "I learned this myself, while tinkering, then expanded my knowledge by tinkering more, and then by having a job doing something similar" kind of field. So that is not new.
    - 5y ago
CraigJPerry 5y ago
For embedded, i would have said C not C++. C is more prevalent still. For some industries where security or correctness guarantees are necessary, you see things like MISRA C used rather than Rust (or cpp).
- michaelsbradley 5y ago
  There's also the Ravenscar profile[1] for Ada and the SPARK language[2]. How those compare in marketshare to MIRSA C, I'm not sure, I'm not in that field, though I've enjoyed reading about them at a conceptual level. [1] https://en.wikipedia.org/wiki/Ravenscar_profile https://en.wikipedia.org/wiki/Ravenscar_profile [2] https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) [&] https://docs.adacore.com/sparkdocs-docs/Examiner_Ravenscar.htm https://docs.adacore.com/sparkdocs-docs/Examiner_Ravenscar.h...
  - oddity 5y ago
    Anecdotally, everything I've seen (hardware drivers) has been in (MISRA) C or a subset of C++. Ironically, many of the alternatives require too much discipline to keep devs happy. MISRA C at least lets them pretend they're in their happy place.
  - dexterhaslem 5y ago
    ive been in the misra c realm a while and romanticized ada, spark, ravenscar profile etc. i think if you have a team and problem that can go 100% in on it, its unmatched (and some industries certainly do, aviation, autopilots, internal fuze controls etc..)
oddity 5y ago
(I'm assuming you're coming from C and don't already know C++ because of the linked article) If the ecosystem that's available is sufficient for your needs on the platforms you care about and you're not interested in easy compatibility with a C/C++ codebase or your existing C knowledge, I would recommend Rust over C++ whenever possible (C is a different question since it fills a slightly different niche and doesn't really have a solid alternative yet imo). Rust has a much simpler and well-chosen set and interaction of features than C++, but it does that by dropping many of the compatibility constraints of C and C++ (and making assumptions that are easier to make in 2021 than 30+ years ago). Compiler errors also more honestly reflect the learning curve, so it can feel more punishing at the start, but has a shorter learning curve to reach functionally correct code, where with C++ you might easily have been using it for 10+ years and still learn you've been doing something wrong the whole time. That's a big set of ifs, though. It's possible that the compiler errors are discouraging enough that C++ might feel like a more comfortable choice (I would encourage you to not let this be your reason unless you're just interested in solving a one-time problem). I keep checking in on Rust to see how small and dependency free I can get the compiled binary, and I usually need a mess of nightly features. The ecosystem is also still a mess. There are a few great libraries, but otherwise it's a minefield of 0.x releases for most dependencies (admittedly, some of the most important ones are autogenerated bindings where the version number is meaningless). Bindings are really easy to write with Rust, however, and it's one of the few languages that really gets that right, but it's nowhere near as convenient as calling/using C or C++ from C++. Most of these issues are consequences of C and C++ having the existing inertia, but it is what it is. Some people want to ship things and not join a community. If you're trying to get a job or just learn: learn both. C++ isn't going to go away completely any time soon, but, with every month that passes, there are fewer and fewer technical reasons to justify starting a new project in it vs Rust. Choosing an inferior tool because it's the only one you understand might often be the correct choice, but it's not a choice you want to have to make.
- ipnon 5y ago
  Thank you for this thoughtful comment. It seems the present moment is a flux for embedded programming languages, there is still a choice to make. Maybe we will be discussing "Modern Rust for C++ Programmers" in a few decades on HN!
Bayart 5y ago
I don't know that « being modern » should ever be a primary concern. Especially when it comes to embedded where stable features and APIs are important. It's largely the realm of C, with some industries working in Ada/SPARK. In terms of its profile, Rust fits the bill for being a good system/embedded programming language some day, but I don't know if it's mature and stable enough yet to be what you'd pick for a really serious job. As for C++, I don't really see the point if you don't have technical debt.
- pjmlp 5y ago
  Some embedded standards like AUTOSAR, require C++ not C.
epistasis 5y ago
I'm not a systems engineer, I just do data analysis and algorithms that sometimes need to go really fast. I only recently investigated rust, and was hugely impressed with it. I regret not investigating it earlier. Language support for ownership and lifetime of variables is such a huge step up for writing code. Trying to do this through as hoc conventions in C, or through RAII in C++, is a lot harder. I haven't yet had a chance to write anything significant in rust beyond a few small test projects, but next time I want to beat Python performance on something I'll be using Rust instead of Cython or C or C++.
- brooksbp 5y ago
  It gets real fun when "going fast" is less about the software and more about what's happening inside the chip!
sharikone 5y ago
I guess so. Some newer libraries, especially if they target "modern backend" stuff like webassembly, websockets, ... are written in Rust. When safety is a concern it could be really preferable. But, say, if you don't have a good support for your platform Rust is not useful. Ditto for most existing codebases. And in any case I don't see why your primary concern should be being modern vs getting things to work well
osivertsson 5y ago
Most places I’ve done embedded dev at have been C or C++. Actually all, with some Lua or assembler sprinkled in. Debugging C++ when your compiler for weird target (SH4, or worse) contains bugs, or when you have some relaxed memory consistency model, is quite a challenge because mapping C++ to assembler is definitely non-trivial. C, even with heavy optimizations, is a breeze comparatively. I would happily join a team that uses Rust in an embedded setting. It shows that they care deeply about doing better than average, and that probably means they are better than average in everything.
- ncmncm 5y ago
  Mapping C++ to assembler is exactly the same as mapping C to assembler, for those operations the languages share. If you are coding reasonably, there aren't any other operations that happen at runtime. C++ does its heavy lifting, preventing bugs, at compile time.
  - osivertsson 5y ago
    For sure C++ does a lot of heavy lifting at compile time, which shows in poor compile and link times, although it is less of a problem today than 25 years ago since hardware performance has increased. I don’t agree that C++ automatically prevents bugs, even though using e.g. RAII can help a bit and leads to maintainable code. If you use exceptions (you probably shouldn’t) there is one more code-path out from your code. That together with constructors/destructors being called and using STL instead of more trivial data-structures often leads to a lot bigger assembler output to trawl through if you need to.
    - ncmncm 5y ago
      C++ doesn't "automatically" prevent bugs. You have to actually, you know, use it. By STL I guess you mean std::string and std::vector. That is wholly optional. I would not use those in a small embedded project, except maybe at startup, and then with a custom, non-freeing bump allocator.
dexterhaslem 5y ago
in my embedded experience (small scrappy teams in contracting) c99 is just barely common place. and very welcome. 99% covers everything I've done. but for absolutely huge mcus where rust is supported, rust is probably welcome and easier to fit

Is Rust preferable for the embedded systems engineer who is primarily concerned with being modern?

by ipnon 5y ago

Is Rust preferable for the embedded systems engineer who is primarily concerned with being modern?

Being modern for its own sake? I suppose it would be preferable, since Rust is newer and evolving rapidly. But if you're concerned with being employed and a wide variety of powerful tooling at your fingertips then C++ is probably a better bet. (Note: I am neither a C++ nor Rust developer, so I don't have a dog in this fight.)

adamnemecek 5y ago

Rust is always preferable.

netr0ute 5y ago
On what merits?
- Inityx 5y ago
  Memory safety, build system, dependency management, the usual
  - adamnemecek 5y ago
    It's just overall productivity.
    - netr0ute 5y ago
      Can you define productivity?
      - smoldesu 5y ago
        I can't speak for everyone, but I spent an unconscionable amount of time managing dependencies and libraries in C++. In Rust, it's the easiest part of my workflow.
        adamnemecek 5y ago
        You can speak for everyone. C++ dependency management is just...I don't even know where to begin.
        dkersten 5y ago
        > You can speak for everyone. Not really. I only use header-only libraries and dependency management is a breeze for me. I check each library out as a git submodule into a third-party subdirectory in my project directory, point the includes path at it and off I go. When I want to upgrade, I pull the git tag/branch/commit I want and recompile. Its pretty simple.
        adamnemecek 5y ago
        I mean that's cool but you are definitely working against the language as opposed to having the language support you. Also this works nicely for self contained dependencies, and much less nicely for not self contained dependencies.
        dkersten 5y ago
        > you are definitely working against the language How so? > Also this works nicely for self contained dependencies, and much less nicely for not self contained dependencies. Doesn't matter. You said: "You can speak for everyone." which is simply not true, as I have outlined. You didn't say anything about not self contained dependencies or whatnot. The person you replied to said "I spent an unconscionable amount of time managing dependencies and libraries in C++" and I... well, don't. So clearly not everybody does.
        5y ago
      - pornel 5y ago
        For example, I almost never need to use a debugger or Valgrind with Rust. Mysterious memory corruption just isn't a thing. Memory leaks are not a problem either (even though technically Rust doesn't claim to prevent all leaks, it does well enough in practice). Rust catches data races, use of non-thread-safe functions, and use-after-free problems across the entire codebase, including (mis)use of 3rd party libraries, at compile time. I can add `.par_iter()` to a loop, and if it compiles, I know it doesn't mangle any data. If it doesn't compile, the compiler points me to the exact struct that needs a refcount, or a mutex, or atomic. That saves me weeks of chasing heisenbugs. In debug builds it checks all integer arithmetic for overflow (no need to wrap types in custom class, works for dependencies too). This has saved my ass a few times. There's a pretty decent standard library, and a good number of quality dependencies that can be installed with a 1-liner. If I need to (de)serialize a struct from JSON, it's a couple of lines. I want to switch that to msgpack instead, 2-line change. I need that compressed? 2 lines again, plugs in easily, and supports serialize-and-compress without an intermediate buffer. Build system uses convention over configuration, so there's no artisanal "build script" to manage, or even an argument which build system sucks less. Dependency management and workspaces work well enough that it's practical to modularize projects into smaller libraries, and actually reuse them. Unit testing is built-in. Doxygen-like generator is also built-in, no config needed. Of course any language can do the same, but having zero friction removes excuses and really helps making people actually use these things.
        adamnemecek 5y ago
        It's just such a step-up that it's not even comparable.
- jimbob45 5y ago
  Is there anything C++ does better at this point? Outside of compatibility, that is.
rvz 5y ago
Too bad there is no first-class production ready GUI library for Rust that I can use for embedded systems. Qt and C++ it is then.
- pjmlp 5y ago
  And on the context of Windows IoT, UWP is all about .NET and C++, with the Rust bindings pretty much still doing baby steps.

dmitrygr 5y ago

Why is "being modern" a concern? Luckily, embedded is not the web, where 5000 frameworks sprout over lunch. I've never heard of anyone in embedded caring about being modern. Only about solving the problems efficiently. So i am curious: why do you ask?

ipnon 5y ago
Embedded engineering seems to be a lost art in the America. The typical American programmer is certainly not an embedded engineer, and our industry and American universities focus mainly on the application layer of both practice and theory. My university's[a] computer architecture and operating systems courses are both taught entirely using simulation, either simulated hardware or virtual machines, and we would certainly never write our own bootloaders or really ever put code to the metal. It all seems more Shenzhen than Silicon Valley, like part of the stack is simply a bygone thing of the past for American software engineers. Neither C nor C++ could be considered new languages, and this seems to contribute to this estimation of embedded engineering as a "lost art." C and C++ give a "here be dragons feeling," that only the best engineers can hope to avoid pointer pitfalls and memory leaks. I wonder if Rust's advances in programming language theory could alleviate this problem. The new generation of programmers I feel I belong to are comfortable with functional programming, advanced types, and facile tooling like NPM. I have personally found embedded engineering underrated in American industry, both for fun and profit. If adopting modern practices leads to further embedded engineering adoption, that would be a worthwhile pursuit for individuals and our community. Perhaps this takes the form of Rust. [a] Top 300 in global ranking, with a standard but not cutting edge computer science program unlike Stanford or CMU. Having gone to only one university I admit this confusion could simply be a failing of my own education.
- dmitrygr 5y ago
  Embedded has always been a "I learned this myself, while tinkering, then expanded my knowledge by tinkering more, and then by having a job doing something similar" kind of field. So that is not new.
  - 5y ago

CraigJPerry 5y ago

For embedded, i would have said C not C++. C is more prevalent still. For some industries where security or correctness guarantees are necessary, you see things like MISRA C used rather than Rust (or cpp).

michaelsbradley 5y ago
There's also the Ravenscar profile[1] for Ada and the SPARK language[2]. How those compare in marketshare to MIRSA C, I'm not sure, I'm not in that field, though I've enjoyed reading about them at a conceptual level. [1] https://en.wikipedia.org/wiki/Ravenscar_profile https://en.wikipedia.org/wiki/Ravenscar_profile [2] https://en.wikipedia.org/wiki/SPARK_(programming_language) https://en.wikipedia.org/wiki/SPARK_(programming_language) [&] https://docs.adacore.com/sparkdocs-docs/Examiner_Ravenscar.htm https://docs.adacore.com/sparkdocs-docs/Examiner_Ravenscar.h...
- oddity 5y ago
  Anecdotally, everything I've seen (hardware drivers) has been in (MISRA) C or a subset of C++. Ironically, many of the alternatives require too much discipline to keep devs happy. MISRA C at least lets them pretend they're in their happy place.
- dexterhaslem 5y ago
  ive been in the misra c realm a while and romanticized ada, spark, ravenscar profile etc. i think if you have a team and problem that can go 100% in on it, its unmatched (and some industries certainly do, aviation, autopilots, internal fuze controls etc..)

oddity 5y ago

(I'm assuming you're coming from C and don't already know C++ because of the linked article) If the ecosystem that's available is sufficient for your needs on the platforms you care about and you're not interested in easy compatibility with a C/C++ codebase or your existing C knowledge, I would recommend Rust over C++ whenever possible (C is a different question since it fills a slightly different niche and doesn't really have a solid alternative yet imo). Rust has a much simpler and well-chosen set and interaction of features than C++, but it does that by dropping many of the compatibility constraints of C and C++ (and making assumptions that are easier to make in 2021 than 30+ years ago). Compiler errors also more honestly reflect the learning curve, so it can feel more punishing at the start, but has a shorter learning curve to reach functionally correct code, where with C++ you might easily have been using it for 10+ years and still learn you've been doing something wrong the whole time. That's a big set of ifs, though. It's possible that the compiler errors are discouraging enough that C++ might feel like a more comfortable choice (I would encourage you to not let this be your reason unless you're just interested in solving a one-time problem). I keep checking in on Rust to see how small and dependency free I can get the compiled binary, and I usually need a mess of nightly features. The ecosystem is also still a mess. There are a few great libraries, but otherwise it's a minefield of 0.x releases for most dependencies (admittedly, some of the most important ones are autogenerated bindings where the version number is meaningless). Bindings are really easy to write with Rust, however, and it's one of the few languages that really gets that right, but it's nowhere near as convenient as calling/using C or C++ from C++. Most of these issues are consequences of C and C++ having the existing inertia, but it is what it is. Some people want to ship things and not join a community. If you're trying to get a job or just learn: learn both. C++ isn't going to go away completely any time soon, but, with every month that passes, there are fewer and fewer technical reasons to justify starting a new project in it vs Rust. Choosing an inferior tool because it's the only one you understand might often be the correct choice, but it's not a choice you want to have to make.

ipnon 5y ago
Thank you for this thoughtful comment. It seems the present moment is a flux for embedded programming languages, there is still a choice to make. Maybe we will be discussing "Modern Rust for C++ Programmers" in a few decades on HN!

Bayart 5y ago

I don't know that « being modern » should ever be a primary concern. Especially when it comes to embedded where stable features and APIs are important. It's largely the realm of C, with some industries working in Ada/SPARK. In terms of its profile, Rust fits the bill for being a good system/embedded programming language some day, but I don't know if it's mature and stable enough yet to be what you'd pick for a really serious job. As for C++, I don't really see the point if you don't have technical debt.

pjmlp 5y ago
Some embedded standards like AUTOSAR, require C++ not C.

epistasis 5y ago

I'm not a systems engineer, I just do data analysis and algorithms that sometimes need to go really fast. I only recently investigated rust, and was hugely impressed with it. I regret not investigating it earlier. Language support for ownership and lifetime of variables is such a huge step up for writing code. Trying to do this through as hoc conventions in C, or through RAII in C++, is a lot harder. I haven't yet had a chance to write anything significant in rust beyond a few small test projects, but next time I want to beat Python performance on something I'll be using Rust instead of Cython or C or C++.

brooksbp 5y ago
It gets real fun when "going fast" is less about the software and more about what's happening inside the chip!

sharikone 5y ago

I guess so. Some newer libraries, especially if they target "modern backend" stuff like webassembly, websockets, ... are written in Rust. When safety is a concern it could be really preferable. But, say, if you don't have a good support for your platform Rust is not useful. Ditto for most existing codebases. And in any case I don't see why your primary concern should be being modern vs getting things to work well

osivertsson 5y ago

Most places I’ve done embedded dev at have been C or C++. Actually all, with some Lua or assembler sprinkled in. Debugging C++ when your compiler for weird target (SH4, or worse) contains bugs, or when you have some relaxed memory consistency model, is quite a challenge because mapping C++ to assembler is definitely non-trivial. C, even with heavy optimizations, is a breeze comparatively. I would happily join a team that uses Rust in an embedded setting. It shows that they care deeply about doing better than average, and that probably means they are better than average in everything.

ncmncm 5y ago
Mapping C++ to assembler is exactly the same as mapping C to assembler, for those operations the languages share. If you are coding reasonably, there aren't any other operations that happen at runtime. C++ does its heavy lifting, preventing bugs, at compile time.
- osivertsson 5y ago
  For sure C++ does a lot of heavy lifting at compile time, which shows in poor compile and link times, although it is less of a problem today than 25 years ago since hardware performance has increased. I don’t agree that C++ automatically prevents bugs, even though using e.g. RAII can help a bit and leads to maintainable code. If you use exceptions (you probably shouldn’t) there is one more code-path out from your code. That together with constructors/destructors being called and using STL instead of more trivial data-structures often leads to a lot bigger assembler output to trawl through if you need to.
  - ncmncm 5y ago
    C++ doesn't "automatically" prevent bugs. You have to actually, you know, use it. By STL I guess you mean std::string and std::vector. That is wholly optional. I would not use those in a small embedded project, except maybe at startup, and then with a custom, non-freeing bump allocator.

dexterhaslem 5y ago

in my embedded experience (small scrappy teams in contracting) c99 is just barely common place. and very welcome. 99% covers everything I've done. but for absolutely huge mcus where rust is supported, rust is probably welcome and easier to fit