5 ms·

I would really love to see more interest in Rust from the embedded industry. With the influx of new developers into embedded programming I think there is an op

by bborud 6y ago

I would really love to see more interest in Rust from the embedded industry. With the influx of new developers into embedded programming I think there is an opportunity.

weinzierl 6y ago
Yes, especially when Rust could be a relief to many pains embedded software suffers from. The counter argument is of course that embedded software is very entrenched. Often we would be happy if we could use a normal C++ compiler like gcc or clang instead of the fragile pieces of art that semiconductor manufacturers give us.
- bborud 6y ago
  I think the embedded world needs a bit of outside blood. Being able to replace C/C++ with something a bit more conducive to helping people develop correct code would be a great plus. But the tooling also needs some help. Good tooling that isn't a nightmare to set up and maintain is crucial.
  - usrusr 6y ago
    [edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers. I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.
    - zozbot234 6y ago
      Rust has plenty of support for compile-time code generation of all kinds. It's generally viewed as something that should be done only as a last-resort, but it's there and fully supported.
      - weinzierl 6y ago
        Do you know good resources for learning about these options?
        estebank 6y ago
        The book has a good intro to their capabilities: https://doc.rust-lang.org/stable/book/ch19-06-macros.html https://doc.rust-lang.org/stable/book/ch19-06-macros.html There are blog posts exploring some of the use cases for them, but it depends a lot on what you want to do.
    - weinzierl 6y ago
      I like how you describe it as "the two-stage nature of embedded development" because that is what in reality it really is. In my opinion replacing the preprocessor with another code generator wouldn't be the best path forward though. I have worked with a bunch of code generators and it has always been a crutch. I think something that ties in with the target language and is aware of the syntax of the target language, like Rust macros, has many advantages. At the same time I do not know enough about Rust macros yet to tell if they are really powerful enough to help here.
    - bborud 6y ago
      The problem of embedded isn't really a lack of implementation languages but rather that the ones that are being used are not very conducive to correctness and that the tooling and operating systems / SDKs / frameworks are awkward. Much of embedded programming is about coping with quirky hardware and nudging bits and bytes around. And coping with rather sloppily put together tooling that requires a lot of hand-cranking. Introducing higher level languages doesn't really solve this. If anything, it would make things worse because it would focus attention where the problem isn't. Adding lots of complexity by adding transpilers for a bunch of languages just makes things more complex and does nothing to solve the actual problems. (Slightly orthogonal: just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release. Choosing Python actually made things worse because Python brings its own unmitigated problems. It screws up your day even before you get to do any programming)
  - weinzierl 6y ago
    Absolutely, and when it comes to tooling Rust is on a very good way in my opinion.
steveklabnik 6y ago
One of the Rust-focused consultancies does a lot of embedded. There’s a whole rust + embedded specific conference now. It is a huge space, but some stuff is certainly being done!
pjmlp 6y ago
Even C needs more love from the embedded industry, given how many still use C89 dialects, even if the tooling might already support something better, let alone languages that attempt to replace C.
- deleted 6y ago
  [deleted]
- Leherenn 6y ago
  C versions after 89 doesn't bring much to be honest. So either you want more than what C can offer you, and usually the option is C++, or you're fine with what you have.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    Well, they are supposed to at least offer a little more of security. And yes, C++ would be a better option, provided that up to date C++ compilers exist at all.
  - hak8or 6y ago
    Bieng able to declare variables after statements in a function is huge, letting you make them const as needed. Also declaring the index variable in a for loop like for(int i =0; i < 10; i++) is extremely helpful. Those two alone are extremely beneficial.
    - Leherenn 6y ago
      True, they are however often available as part of compiler extensions.
ktrl 6y ago
One roadblock is that many in the embedded software industry uses proprietary IDEs and tools like Keil, Atmel Studio, CCStudio and STM32CubeIDE. These propietary IDEs and tools are often based on Eclipse or Visual Studio Isolated Shell. How good is the Rust support in Eclipse and Visual Studio? Visual Studio should not be confused with Visual Studio Code. The latter has great Rust support.
- nicoburns 6y ago
  Wouldn't escaping this proprietary tooling be one of the big benefits of switching to Rust?
  - pjmlp 6y ago
    Most embedded developers don't have any issues with proprietary tooling, they embrace them. If you want their buy-in into other toolchains, you need to meet them where they are.
    - bborud 6y ago
      I wouldn't say that they embrace them. I'd say they accept them. Often because this is what they are used to. It is mostly newcomers to the embedded programming scene that go on about tooling because they're used to better tooling from non-embedded development. I think one should pay attention to the newcomers and try to learn from them.
- steveklabnik 6y ago
  Eclipse had a plugin that IIRC was supported by the foundation, but I’ve never used it.
detaro 6y ago
I'm actually positively surprised how well that field develops, compared to how slow it usually operates. Also, "embedded" is a massive field with very different cultures and needs.

by bborud 6y ago

I would really love to see more interest in Rust from the embedded industry. With the influx of new developers into embedded programming I think there is an opportunity.

weinzierl 6y ago

Yes, especially when Rust could be a relief to many pains embedded software suffers from. The counter argument is of course that embedded software is very entrenched. Often we would be happy if we could use a normal C++ compiler like gcc or clang instead of the fragile pieces of art that semiconductor manufacturers give us.

bborud 6y ago
I think the embedded world needs a bit of outside blood. Being able to replace C/C++ with something a bit more conducive to helping people develop correct code would be a great plus. But the tooling also needs some help. Good tooling that isn't a nightmare to set up and maintain is crucial.
- usrusr 6y ago
  [edit: moved from another parent where it was less on-topic] Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers. I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.
  - zozbot234 6y ago
    Rust has plenty of support for compile-time code generation of all kinds. It's generally viewed as something that should be done only as a last-resort, but it's there and fully supported.
    - weinzierl 6y ago
      Do you know good resources for learning about these options?
      - estebank 6y ago
        The book has a good intro to their capabilities: https://doc.rust-lang.org/stable/book/ch19-06-macros.html https://doc.rust-lang.org/stable/book/ch19-06-macros.html There are blog posts exploring some of the use cases for them, but it depends a lot on what you want to do.
  - weinzierl 6y ago
    I like how you describe it as "the two-stage nature of embedded development" because that is what in reality it really is. In my opinion replacing the preprocessor with another code generator wouldn't be the best path forward though. I have worked with a bunch of code generators and it has always been a crutch. I think something that ties in with the target language and is aware of the syntax of the target language, like Rust macros, has many advantages. At the same time I do not know enough about Rust macros yet to tell if they are really powerful enough to help here.
  - bborud 6y ago
    The problem of embedded isn't really a lack of implementation languages but rather that the ones that are being used are not very conducive to correctness and that the tooling and operating systems / SDKs / frameworks are awkward. Much of embedded programming is about coping with quirky hardware and nudging bits and bytes around. And coping with rather sloppily put together tooling that requires a lot of hand-cranking. Introducing higher level languages doesn't really solve this. If anything, it would make things worse because it would focus attention where the problem isn't. Adding lots of complexity by adding transpilers for a bunch of languages just makes things more complex and does nothing to solve the actual problems. (Slightly orthogonal: just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release. Choosing Python actually made things worse because Python brings its own unmitigated problems. It screws up your day even before you get to do any programming)
- weinzierl 6y ago
  Absolutely, and when it comes to tooling Rust is on a very good way in my opinion.

steveklabnik 6y ago

One of the Rust-focused consultancies does a lot of embedded. There’s a whole rust + embedded specific conference now. It is a huge space, but some stuff is certainly being done!

pjmlp 6y ago

Even C needs more love from the embedded industry, given how many still use C89 dialects, even if the tooling might already support something better, let alone languages that attempt to replace C.

deleted 6y ago
[deleted]
Leherenn 6y ago
C versions after 89 doesn't bring much to be honest. So either you want more than what C can offer you, and usually the option is C++, or you're fine with what you have.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- pjmlp 6y ago
  Well, they are supposed to at least offer a little more of security. And yes, C++ would be a better option, provided that up to date C++ compilers exist at all.
- hak8or 6y ago
  Bieng able to declare variables after statements in a function is huge, letting you make them const as needed. Also declaring the index variable in a for loop like for(int i =0; i < 10; i++) is extremely helpful. Those two alone are extremely beneficial.
  - Leherenn 6y ago
    True, they are however often available as part of compiler extensions.

ktrl 6y ago

One roadblock is that many in the embedded software industry uses proprietary IDEs and tools like Keil, Atmel Studio, CCStudio and STM32CubeIDE. These propietary IDEs and tools are often based on Eclipse or Visual Studio Isolated Shell. How good is the Rust support in Eclipse and Visual Studio? Visual Studio should not be confused with Visual Studio Code. The latter has great Rust support.

nicoburns 6y ago
Wouldn't escaping this proprietary tooling be one of the big benefits of switching to Rust?
- pjmlp 6y ago
  Most embedded developers don't have any issues with proprietary tooling, they embrace them. If you want their buy-in into other toolchains, you need to meet them where they are.
  - bborud 6y ago
    I wouldn't say that they embrace them. I'd say they accept them. Often because this is what they are used to. It is mostly newcomers to the embedded programming scene that go on about tooling because they're used to better tooling from non-embedded development. I think one should pay attention to the newcomers and try to learn from them.
steveklabnik 6y ago
Eclipse had a plugin that IIRC was supported by the foundation, but I’ve never used it.

detaro 6y ago

I'm actually positively surprised how well that field develops, compared to how slow it usually operates. Also, "embedded" is a massive field with very different cultures and needs.