4 ms·

Great blog post. It's been wonderful to see rust take off in the space and the approaches the folks in the embedded wg and ecosystem have come up with. The cort

by leshow 7y ago

Great blog post. It's been wonderful to see rust take off in the space and the approaches the folks in the embedded wg and ecosystem have come up with. The cortex-m starter projects, embedded-hal tying the ecosystem together, and various intro books like "discovery". I never would have thought I would explore anything this "low level" but rust has opened those doors for me.

_bxg1 7y ago
I hated using C/C++ in college because of all the arcane runtime errors and how hard they could be to debug, as well as the finicky tooling/library landscape, the mental overhead of object lifetime management, etc. Coming back around, Rust has given me my first opportunity to really appreciate and enjoy the more gratifying aspects of lower-level programming.
- rvz 7y ago
  Well it's exhausting to keep hearing the same old C/C++/Rust/Zig anecdotal testimonials of the day which might easily sway the decision for some but may bring misery for others as we are now starting to get credible alternatives in low-level programming. Hence this, from the perspective of a typical embedded developer shop across the street with a medium sized team of 25+ engineers, would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future? The choice is yours.
  - 3pt14159 7y ago
    This comment reminds me of what Java and PHP devs were telling me about Merb / Rails in 2008. I'm not saying it's going to go the same way, but I'd bet rust continues to gain traction to the point of escape velocity in embedded systems.
    - jononor 7y ago
      Embedded Systems is considerably more conservative than web development. For example, many greenfield projects are still C over C++. And most new C projects are probably C99 instead of C11. But yes, I believe Rust will continue to make progress and pick up pace. But it will be a slow process. And C is not going away anytime soon.
      - wbl 7y ago
        C11 didn't change much for uniprocessors iirc.
  - unlinked_dll 7y ago
    I think you overestimate the difficulty in "getting used to" something new when it comes to a PL (and rust, even though it has a bit of a learning curve for OOP folks). I don't want to use C/C++ for embedded projects in the same way that I don't want to use a hand drill when I have a nice corded Milwaukee power drill on the workbench.
  - ksec 7y ago
    >C/C++/Rust/Zig You can now add Zen to that list, seems to be gaining from traction in the Japanese embedded programming community.
    - Jayschwa 7y ago
      Zen appears to be a fork of Zig.
    - 59nadir 7y ago
      Zen is just a copy-paste of Zig with cringy people and marketing on top, it's not a real language.
      - ksec 7y ago
        Zen is sponsored by a Japanese company which also happens to be sponsoring the top contributors in Zig. As with all open source project you cant please everyone, and if you dont like it you can always fork it and make your own version. Which is exactly what they did.
  - jononor 7y ago
    As the CTO of a IoT sensor manufacturer doing a new project recently, I chose C for firmware over C++ and Rust (and Nim and Zig). C++, Rust etc would be technically more suitable languages. But it is just much easier to get a hold of competent people for firmware development in C than C++, and certainly than Rust. Both from microcontroller vendors, third-party vendors, development houses, independent consultants and new hires. If someone know microcontroller firmware development, they generally know C. Sometimes something else in addition, but always C.
    - monoideism 7y ago
      If such a large number of JavaScript and Ruby devs could learn Rust relatively quickly[0], I'm hoping that a firmware dev could as well. The only semi-hard concept about Rust is lifetimes, and that's getting much easier now. I mean, if you're not allocating to the heap, Rust memory management is not as useful, I concede. But once you learn to properly model data using algebraic data types (in Rust: enums and tuples), it's a huge, huge gamechanger in how you write programs. You can literally make it impossible to represent illegal states, thus saving massive amounts of error handling[1]. Functional devs have been enjoying this for decades, and now it's available to embedded world via Rust. 0. Seriously, a huge number of active Rust devs come from those communities. Even a significant number of Rust compiler devs come from Ruby and JavaScript backgrounds. 1. Yes, with some clever techniques, this is also possible - to a certain extent - in languages without ADTs, but only to a very limited extent. It becomes simple and natural with ADTs
      - larusso 7y ago
        For me Rust keeps the perfect balance between having all these awesome functional concepts but still be a language that works on real world state problems. Don’t get me wrong. I like Haskells Monads etc. But they try to hide the fact that we have state and all it’s wonderful side effects ;). Rust embraces state but with a clever system that feels always one step ahead of you. I also think a paradigm shift will happen when it comes to c. Yes it is used everywhere. Yes you get more developers now. Yes it has more libraries etc. But this was also true for the languages that where used before c. And I think Rust also has the chance to topple over JS in the web world. Lets see. I enjoy Rust at the moment very much and play around with it in all kinds of fields. It is already my number one language for command line utilities :)
  - batmansmk 7y ago
    I take the standard of tomorrow any day. Or at least would dare to experiment with it more with putting a small team to make a module with it. Rust has enough steam now, it would be irresponsible to bet against it.
  - fra 7y ago
    I think one can both be excited about Rust and acknowledge that for most projects C is still the way to go. The libraries, communities, compilers, vendor support, ...etc. is much more mature on the C side of things and will remain that way for a while. At the same time, Rust is getting to the point where early adopters can start using it for their projects. Those are the people who will make Rust a full class option in the future.
    - zozbot234 7y ago
      Rust can interoperate with C libraries, it's a pretty substantial part of its value proposition. At the same time, it's true that C has way better compiler support for weird embedded targets, and it's also a comparatively mature language that's not going to change much over the years, with a vendor-independent standard definition. For some projects, these things might be important.
      - adwn 7y ago
        > Rust can interoperate with C libraries True, but speaking as an embedded developer and Rust fan: embedded C libraries just love their #defines in public APIs. This makes interfacing with them from anything but C or C++ more cumbersome, because you can't just declare "extern" functions, you also have to translate the #define macros, which are sometimes non-trivial.
  - taneq 7y ago
    > would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future? Whichever one works with the hardware? >.> I don't think embedded folks are too used to having choices, usually we just take whatever toolchain the chip manufacturer gives us, so when there's a second option it's scary and strange.
  - detaro 7y ago
    And maybe the parent was talking about their experience working in a really small team, or on small embedded components of a larger system, or on hobby projects, and has entirely different considerations. Someone saying "I enjoy using Rust for this" does not mean "everyone has to use Rust now".
  - swsieber 7y ago
    Like the article is exhausting? Or the anecdotes about Rust in the comments on an article... about Rust?
  - littlestymaar 7y ago
    That's the same kind of choice than the one to move from asm to C a few decades ago. Of course, there's many situations where switching to the new tech isn't worth it, but in the long run it will become a more and more obvious choice (assuming the language takes off, the ecosystem will mature and the number of developers will rise).

by leshow 7y ago

_bxg1 7y ago

I hated using C/C++ in college because of all the arcane runtime errors and how hard they could be to debug, as well as the finicky tooling/library landscape, the mental overhead of object lifetime management, etc. Coming back around, Rust has given me my first opportunity to really appreciate and enjoy the more gratifying aspects of lower-level programming.

rvz 7y ago
Well it's exhausting to keep hearing the same old C/C++/Rust/Zig anecdotal testimonials of the day which might easily sway the decision for some but may bring misery for others as we are now starting to get credible alternatives in low-level programming. Hence this, from the perspective of a typical embedded developer shop across the street with a medium sized team of 25+ engineers, would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future? The choice is yours.
- 3pt14159 7y ago
  This comment reminds me of what Java and PHP devs were telling me about Merb / Rails in 2008. I'm not saying it's going to go the same way, but I'd bet rust continues to gain traction to the point of escape velocity in embedded systems.
  - jononor 7y ago
    Embedded Systems is considerably more conservative than web development. For example, many greenfield projects are still C over C++. And most new C projects are probably C99 instead of C11. But yes, I believe Rust will continue to make progress and pick up pace. But it will be a slow process. And C is not going away anytime soon.
    - wbl 7y ago
      C11 didn't change much for uniprocessors iirc.
- unlinked_dll 7y ago
  I think you overestimate the difficulty in "getting used to" something new when it comes to a PL (and rust, even though it has a bit of a learning curve for OOP folks). I don't want to use C/C++ for embedded projects in the same way that I don't want to use a hand drill when I have a nice corded Milwaukee power drill on the workbench.
- ksec 7y ago
  >C/C++/Rust/Zig You can now add Zen to that list, seems to be gaining from traction in the Japanese embedded programming community.
  - Jayschwa 7y ago
    Zen appears to be a fork of Zig.
  - 59nadir 7y ago
    Zen is just a copy-paste of Zig with cringy people and marketing on top, it's not a real language.
    - ksec 7y ago
      Zen is sponsored by a Japanese company which also happens to be sponsoring the top contributors in Zig. As with all open source project you cant please everyone, and if you dont like it you can always fork it and make your own version. Which is exactly what they did.
- jononor 7y ago
  As the CTO of a IoT sensor manufacturer doing a new project recently, I chose C for firmware over C++ and Rust (and Nim and Zig). C++, Rust etc would be technically more suitable languages. But it is just much easier to get a hold of competent people for firmware development in C than C++, and certainly than Rust. Both from microcontroller vendors, third-party vendors, development houses, independent consultants and new hires. If someone know microcontroller firmware development, they generally know C. Sometimes something else in addition, but always C.
  - monoideism 7y ago
    If such a large number of JavaScript and Ruby devs could learn Rust relatively quickly[0], I'm hoping that a firmware dev could as well. The only semi-hard concept about Rust is lifetimes, and that's getting much easier now. I mean, if you're not allocating to the heap, Rust memory management is not as useful, I concede. But once you learn to properly model data using algebraic data types (in Rust: enums and tuples), it's a huge, huge gamechanger in how you write programs. You can literally make it impossible to represent illegal states, thus saving massive amounts of error handling[1]. Functional devs have been enjoying this for decades, and now it's available to embedded world via Rust. 0. Seriously, a huge number of active Rust devs come from those communities. Even a significant number of Rust compiler devs come from Ruby and JavaScript backgrounds. 1. Yes, with some clever techniques, this is also possible - to a certain extent - in languages without ADTs, but only to a very limited extent. It becomes simple and natural with ADTs
    - larusso 7y ago
      For me Rust keeps the perfect balance between having all these awesome functional concepts but still be a language that works on real world state problems. Don’t get me wrong. I like Haskells Monads etc. But they try to hide the fact that we have state and all it’s wonderful side effects ;). Rust embraces state but with a clever system that feels always one step ahead of you. I also think a paradigm shift will happen when it comes to c. Yes it is used everywhere. Yes you get more developers now. Yes it has more libraries etc. But this was also true for the languages that where used before c. And I think Rust also has the chance to topple over JS in the web world. Lets see. I enjoy Rust at the moment very much and play around with it in all kinds of fields. It is already my number one language for command line utilities :)
- batmansmk 7y ago
  I take the standard of tomorrow any day. Or at least would dare to experiment with it more with putting a small team to make a module with it. Rust has enough steam now, it would be irresponsible to bet against it.
- fra 7y ago
  I think one can both be excited about Rust and acknowledge that for most projects C is still the way to go. The libraries, communities, compilers, vendor support, ...etc. is much more mature on the C side of things and will remain that way for a while. At the same time, Rust is getting to the point where early adopters can start using it for their projects. Those are the people who will make Rust a full class option in the future.
  - zozbot234 7y ago
    Rust can interoperate with C libraries, it's a pretty substantial part of its value proposition. At the same time, it's true that C has way better compiler support for weird embedded targets, and it's also a comparatively mature language that's not going to change much over the years, with a vendor-independent standard definition. For some projects, these things might be important.
    - adwn 7y ago
      > Rust can interoperate with C libraries True, but speaking as an embedded developer and Rust fan: embedded C libraries just love their #defines in public APIs. This makes interfacing with them from anything but C or C++ more cumbersome, because you can't just declare "extern" functions, you also have to translate the #define macros, which are sometimes non-trivial.
- taneq 7y ago
  > would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future? Whichever one works with the hardware? >.> I don't think embedded folks are too used to having choices, usually we just take whatever toolchain the chip manufacturer gives us, so when there's a second option it's scary and strange.
- detaro 7y ago
  And maybe the parent was talking about their experience working in a really small team, or on small embedded components of a larger system, or on hobby projects, and has entirely different considerations. Someone saying "I enjoy using Rust for this" does not mean "everyone has to use Rust now".
- swsieber 7y ago
  Like the article is exhausting? Or the anecdotes about Rust in the comments on an article... about Rust?
- littlestymaar 7y ago
  That's the same kind of choice than the one to move from asm to C a few decades ago. Of course, there's many situations where switching to the new tech isn't worth it, but in the long run it will become a more and more obvious choice (assuming the language takes off, the ecosystem will mature and the number of developers will rise).