7 ms·

I'm not using this language because the syntax is really heavy and definitely not my cup of tea. I'm puzzled by the ambitions to market this language for the em

I'm not using this language because the syntax is really heavy and definitely not my cup of tea. I'm puzzled by the ambitions to market this language for the embedded world. The embedded world is full of electronics engineers that are writing code as part of their job. If experienced developers are finding this language overwhelming, how are you going to convince the electronics guys to adopt it instead of using plain old C? Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard...

leafario2 6y ago
I am an embedded software dev and Rust would fit my job well, but I see what you are saying. However, embedded is not all for Rust and not all embedded is done by EEs. Systems programming goes from bare metal up to things like browsers and databases...
dataking 6y ago
Rust's type system is complicated for a reason. It makes explicit the reasoning that is necessary to allocate and access memory correctly without reference counting or garbage collection. Sure it is easier to start writing C but I believe it is overall faster to write and debug a Rust program because C requires additional sanitization and fuzzing to catch errors. To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)
- msie 6y ago
  I don’t know. Rust has all these high level features that also contribute to it’s complexity too. Strip those out and you may have a simpler language.
- hvasilev 6y ago
  I think this profession is hard enough as it is. I don't think you need another daily source of annoyance like reading code with a difficult syntax or fighting meaninglessly with the borrow checker. I understand the motivations for this language, but I don't like the tradeoffs on a personal level. Definitely not my cup of tea.
  - aldanor 6y ago
    You don't "fight the borrow checker" after a while; rather, you enjoy the fact that it exists. "Difficult syntax" becomes enjoyable as well, and it's all subjective. > I think this profession is hard enough as it is. Exactly, I think so too. Don't think I need another source of annoyance like spending days on digging at obscure segfaults and data races caused by logical mutability mistakes.
  - danieldk 6y ago
    But you don’t fight meaninglessly with the borrows checker. For me, this was only the first few weeks. Once you know the (simple) borrowing rules, it is rarely a problem anymore. It only rears its head every now and then when you know something is valid, but the borrows checker is not able to infer it. Another dimension to it is that the borrows checker rules also apply in most other languages if you want to write valid code. They are just not enforced and you have to rely on your own discipline instead (which humans are bad at).
  - zozbot234 6y ago
    Memory safety errors are a far bigger "annoyance" to the profession than dealing with a slightly more complex (but still quite elegant) syntax or understanding borrowck diagnostics ("fighting with the borrow checker"). It's not even close. The problem with unsafe programming in the traditional C style (with its heavy reliance on shared, mutable, possibly aliased pointers) is that it's inherently non-compositional: proving safety or correctness of such a piece of code is a 'global' problem that cannot be meaningfully decomposed or modularized. That's why Rust's choice of explicitly restricting these features to "unsafe" blocks feels intuitively right - the "safe" part of Rust is essentially the part that can be worked with in a highly modular way, where safety is checked 'locally' via a type system. Future versions of Rust may well make some currently-unsafe features slightly easier to use, perhaps even more idiomatic in a way that might appeal to C developers, but some inherent constraints will remain.
    - sai_c 6y ago
      I think (for this discussion) we should have a more clear definition of embedded. Yes, ARM processors are used more and more, but there are really A LOT of embedded systems out there, which are still, for example, 8 bit. As an embedded dev, who is using pretty much everything from 8 to 64 bit, the kind of memory safety errors you talk about I have yet to see with on anything based on (say) a 8051 or PIC. On a system without OS and without dynamic memory allocation, the borrow checker does not buy you much. It's a different story with an ARM processor and an OS (real-time or not does not matter). Of course Rust has a more powerful type system, but my experience is, that the preferences for a C type type system dominate the embedded world. Not because it is better or simpler, but because most embedded devs actually like low level. They are simply not interested in type driven development (yes it's just their personal taste) and its benefits. Or let me say it like this. I see two kinds of embedded devs: - Those who abstract way the problem ("It's all just a big char array.", "It's all just ints.", "It's all just data structures"). - Those who abstract away the machine ("It's all just objects.", "It's all just types."). Right now, my observations tell me that the first group is still dominating. Time will tell if this is going to change.
- pjmlp 6y ago
  Given that C++ has barely made a dent in some of those domains, after 40 years of trying, any Rust advocacy towards that target market can take a lesson or two from why those engineers are unwilling to move beyond C89 + OEM specific extensions.
  - raxxorrax 6y ago
    The problem is that embedded systems today can range from a 1Mhz µC to a complete PC like a Raspberry Pie. While memory management is important for the latter, the former doesn't like any dynamically allocated memory at all. Also many processor manufacturers have hundreds of different models with similar but different port mappings. They often supply C-header files which helps making your software compatible with numerous different processor types. So even while Rust has a macro system, it would need to be adapted by those manufacturers or C will likely stay the more convenient choice for the time being.
  - mlindner 6y ago
    Please tell me how I can shut off the heap and still use portions of the C++ standard library? You can do that with Rust. C++ just wasn't designed with embedded in mind.
    - pjmlp 6y ago
      Easy, by actually learning how pros do it. https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default.aspx https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default... https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf https://www.autosar.org/fileadmin/user_upload/standards/adap... https://en.cppreference.com/w/cpp/freestanding https://en.cppreference.com/w/cpp/freestanding Certifications that Rust has yet to achieve.
    - zozbot234 6y ago
      C++ has custom allocators and in-place object construction via placement new. That's even better support than current Rust, which is still limited to a single, global allocator for the entire program.
- dustinmoris 6y ago
  There’s that saying we have: I dress slowly because I’m in a rush.
- sai_c 6y ago
  Yeah, but I think there is another saying that is still true in 2020: "Time is money". ;-). Edit: Corrected typo.
jasonwatkinspdx 6y ago
The article and the links it references do a good job of explaining the arguments. A short summary: * Rust's no_std means you can run bare metal with less memory overhead than even newlib based c * no_std also makes it easier to port to new platforms, as nonportable parts are isolated out of the std lib * algebraic data types and in particular enums that can carry disjoint associated data reduce the number of error prone magic constants and casts in your code, as well as catching all missing switch cases * unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase * The borrow check makes you work more, but in many cases this is justified by it leading you to a less brittle design The examples, particularly on cliff's blog post, make pretty convincing arguments oo these points imo. I also wouldn't discount EEs so much. There's plenty of complexity to Verilog and all the other tools they use.
- saurik 6y ago
  If you are using no_std isn't that the same as just not having a C standard library? I have been programming in C/C++ for over 25 years in ridiculously restricted contexts--even using it to compile tiny trampolines and the such--and I have no clue what you might mean that Rust could possibly have a smaller runtime library than C's "literally it comes with and uses nothing as the C standard library is nothing more than an optional library that most embedded people don't use".
  - nindalf 6y ago
    > If you are using no_std isn't that the same as just not having a C standard library No. no_std means that all standard library functions that involve allocation aren't available. Things like std::collections::{Vec, HashMap} etc. You have access to std::core (https://doc.rust-lang.org/core/index.html https://doc.rust-lang.org/core/index.html), which is pretty useful.
    - chrismorgan 6y ago
      Technical correction: core is a crate, not a module in the std crate. Your paths will be core::, not std::core::.
detaro 6y ago
It's a large field. I don't think anyone in the Rust world expects it to make a large dent against embedded C anytime soon - rather a subset of embedded developers who would like to not have to use just C are working on it because they would personally want something "better" for their niches. And as the article describes, Rust has good foundations to be able to fit that role, compared to many other languages.
bsder 6y ago
> If experienced developers are finding this language overwhelming, how are you going to convince the electronics guys to adopt it instead of using plain old C? Because embedded software is increasingly networked (BLE, TCP/IP, ZigBee, etc.) and you can continue writing your communication stacks in C and having memory corruption security vulnerabilities or you can suck it up and try something else for once. > Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard... 1) The embedded world has effectively converged on ARM. This means that the toolchain is whatever ARM shoves out and HALs and SDKs will comply or get no traction. It also means that you can use actual, real software tooling (VSCode, Meson, Ninja, etc.) instead of "Yet Another Broken Vendor IDE". It's soooo compelling that I personally can run rings around some vendor teams. To be fair--this is NOT limited to Rust. VSCode and its ecosystem enables even C programmers to be stupidly more productive. However, the embedded Rust folks seem to rattle the VSCode folks cage quite a bit more than just plain embedded C folks--this keeps the VSCode guys quite a bit more honest about cross-platform support. 2) Anything RISC-V is in flux, and folks like Bryan Cantrill are leading the charge so the toolchain will be forced to accommodate more than "just C". 3) Even if Rust isn't the answer, you should root for its tooling to break the C hegemony. If Rust finally forces C tooling to acknowledge that "Hey, just maybe we should think about playing nicely in the sandbox and have some useful API's instead of telling everybody to cope or leave because we're the 500lb gorilla.", the successor to Rust will have a vastly easier time.
- scoutt 6y ago
  See. Not all the problems in embedded are network security risks. If you are evangelizing Rust, please stop trying to lure embedded developers with "networks haxxor buffer overflow" FUD because it's simply not going to work. For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. Edit to add: is not that security bugs are not important, but is not what we (embedded developers) are always chasing or taking away our sleep at night. Embedded is wide enough beyond computer networks. Please take a look at the room around you. Can you count every little chip in there? Including the one in your keyboard, LED lamps, coffee machine? Are all these ARM? NO. Are all these connected to the network? NO. Do you expect them to work 100% of the time without hiccups? YES, and they probably do without you noticing it. And they are probably running 1000s of lines of C. That's embedded.
croh 6y ago
I can understand you. This is the reason, I miss lisp. Why language designers ignore syntax ? Syntax should be CONSISTENT, INTUTIVE and LESS AMBIGUOS (there should be one good way to do thing). As a enduser, I want to focus on solving problem at hand, instead tackling/remembering language syntax/quirks(and new apis). Let me give a very simple example in golang. Function returning single value and function returing multiple values. func foo(x int, y int) int {} func bar(x int, y int) (int, int) {} Even though below synatx works, func bar(x int, y int)(int) {} why there is a additional way to do it by removing parenthesis ? This looks very simple example. But it breaks consistancy of syntax. Adds 2 rules to remember over what saving 2 keystrokes ? In the age of 100x full stack devs, life really sucks.

leafario2 6y ago

I am an embedded software dev and Rust would fit my job well, but I see what you are saying. However, embedded is not all for Rust and not all embedded is done by EEs. Systems programming goes from bare metal up to things like browsers and databases...

dataking 6y ago

Rust's type system is complicated for a reason. It makes explicit the reasoning that is necessary to allocate and access memory correctly without reference counting or garbage collection. Sure it is easier to start writing C but I believe it is overall faster to write and debug a Rust program because C requires additional sanitization and fuzzing to catch errors. To quote Grissom from CSI: I've learned that sometimes you can go faster by going slow ;-)

msie 6y ago
I don’t know. Rust has all these high level features that also contribute to it’s complexity too. Strip those out and you may have a simpler language.
hvasilev 6y ago
I think this profession is hard enough as it is. I don't think you need another daily source of annoyance like reading code with a difficult syntax or fighting meaninglessly with the borrow checker. I understand the motivations for this language, but I don't like the tradeoffs on a personal level. Definitely not my cup of tea.
- aldanor 6y ago
  You don't "fight the borrow checker" after a while; rather, you enjoy the fact that it exists. "Difficult syntax" becomes enjoyable as well, and it's all subjective. > I think this profession is hard enough as it is. Exactly, I think so too. Don't think I need another source of annoyance like spending days on digging at obscure segfaults and data races caused by logical mutability mistakes.
- danieldk 6y ago
  But you don’t fight meaninglessly with the borrows checker. For me, this was only the first few weeks. Once you know the (simple) borrowing rules, it is rarely a problem anymore. It only rears its head every now and then when you know something is valid, but the borrows checker is not able to infer it. Another dimension to it is that the borrows checker rules also apply in most other languages if you want to write valid code. They are just not enforced and you have to rely on your own discipline instead (which humans are bad at).
- zozbot234 6y ago
  Memory safety errors are a far bigger "annoyance" to the profession than dealing with a slightly more complex (but still quite elegant) syntax or understanding borrowck diagnostics ("fighting with the borrow checker"). It's not even close. The problem with unsafe programming in the traditional C style (with its heavy reliance on shared, mutable, possibly aliased pointers) is that it's inherently non-compositional: proving safety or correctness of such a piece of code is a 'global' problem that cannot be meaningfully decomposed or modularized. That's why Rust's choice of explicitly restricting these features to "unsafe" blocks feels intuitively right - the "safe" part of Rust is essentially the part that can be worked with in a highly modular way, where safety is checked 'locally' via a type system. Future versions of Rust may well make some currently-unsafe features slightly easier to use, perhaps even more idiomatic in a way that might appeal to C developers, but some inherent constraints will remain.
  - sai_c 6y ago
    I think (for this discussion) we should have a more clear definition of embedded. Yes, ARM processors are used more and more, but there are really A LOT of embedded systems out there, which are still, for example, 8 bit. As an embedded dev, who is using pretty much everything from 8 to 64 bit, the kind of memory safety errors you talk about I have yet to see with on anything based on (say) a 8051 or PIC. On a system without OS and without dynamic memory allocation, the borrow checker does not buy you much. It's a different story with an ARM processor and an OS (real-time or not does not matter). Of course Rust has a more powerful type system, but my experience is, that the preferences for a C type type system dominate the embedded world. Not because it is better or simpler, but because most embedded devs actually like low level. They are simply not interested in type driven development (yes it's just their personal taste) and its benefits. Or let me say it like this. I see two kinds of embedded devs: - Those who abstract way the problem ("It's all just a big char array.", "It's all just ints.", "It's all just data structures"). - Those who abstract away the machine ("It's all just objects.", "It's all just types."). Right now, my observations tell me that the first group is still dominating. Time will tell if this is going to change.
pjmlp 6y ago
Given that C++ has barely made a dent in some of those domains, after 40 years of trying, any Rust advocacy towards that target market can take a lesson or two from why those engineers are unwilling to move beyond C89 + OEM specific extensions.
- raxxorrax 6y ago
  The problem is that embedded systems today can range from a 1Mhz µC to a complete PC like a Raspberry Pie. While memory management is important for the latter, the former doesn't like any dynamically allocated memory at all. Also many processor manufacturers have hundreds of different models with similar but different port mappings. They often supply C-header files which helps making your software compatible with numerous different processor types. So even while Rust has a macro system, it would need to be adapted by those manufacturers or C will likely stay the more convenient choice for the time being.
- mlindner 6y ago
  Please tell me how I can shut off the heap and still use portions of the C++ standard library? You can do that with Rust. C++ just wasn't designed with embedded in mind.
  - pjmlp 6y ago
    Easy, by actually learning how pros do it. https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default.aspx https://www.misra.org.uk/Activities/MISRAC/tabid/171/Default... https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf https://www.autosar.org/fileadmin/user_upload/standards/adap... https://en.cppreference.com/w/cpp/freestanding https://en.cppreference.com/w/cpp/freestanding Certifications that Rust has yet to achieve.
  - zozbot234 6y ago
    C++ has custom allocators and in-place object construction via placement new. That's even better support than current Rust, which is still limited to a single, global allocator for the entire program.
dustinmoris 6y ago
There’s that saying we have: I dress slowly because I’m in a rush.
sai_c 6y ago
Yeah, but I think there is another saying that is still true in 2020: "Time is money". ;-). Edit: Corrected typo.

jasonwatkinspdx 6y ago

The article and the links it references do a good job of explaining the arguments. A short summary: * Rust's no_std means you can run bare metal with less memory overhead than even newlib based c * no_std also makes it easier to port to new platforms, as nonportable parts are isolated out of the std lib * algebraic data types and in particular enums that can carry disjoint associated data reduce the number of error prone magic constants and casts in your code, as well as catching all missing switch cases * unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase * The borrow check makes you work more, but in many cases this is justified by it leading you to a less brittle design The examples, particularly on cliff's blog post, make pretty convincing arguments oo these points imo. I also wouldn't discount EEs so much. There's plenty of complexity to Verilog and all the other tools they use.

saurik 6y ago
If you are using no_std isn't that the same as just not having a C standard library? I have been programming in C/C++ for over 25 years in ridiculously restricted contexts--even using it to compile tiny trampolines and the such--and I have no clue what you might mean that Rust could possibly have a smaller runtime library than C's "literally it comes with and uses nothing as the C standard library is nothing more than an optional library that most embedded people don't use".
- nindalf 6y ago
  > If you are using no_std isn't that the same as just not having a C standard library No. no_std means that all standard library functions that involve allocation aren't available. Things like std::collections::{Vec, HashMap} etc. You have access to std::core (https://doc.rust-lang.org/core/index.html https://doc.rust-lang.org/core/index.html), which is pretty useful.
  - chrismorgan 6y ago
    Technical correction: core is a crate, not a module in the std crate. Your paths will be core::, not std::core::.

detaro 6y ago

It's a large field. I don't think anyone in the Rust world expects it to make a large dent against embedded C anytime soon - rather a subset of embedded developers who would like to not have to use just C are working on it because they would personally want something "better" for their niches. And as the article describes, Rust has good foundations to be able to fit that role, compared to many other languages.

bsder 6y ago

> If experienced developers are finding this language overwhelming, how are you going to convince the electronics guys to adopt it instead of using plain old C? Because embedded software is increasingly networked (BLE, TCP/IP, ZigBee, etc.) and you can continue writing your communication stacks in C and having memory corruption security vulnerabilities or you can suck it up and try something else for once. > Also in this world all major HALs and SDKs are written in C. The toolchains usually are very fixed, since doing embedded systems is hard... 1) The embedded world has effectively converged on ARM. This means that the toolchain is whatever ARM shoves out and HALs and SDKs will comply or get no traction. It also means that you can use actual, real software tooling (VSCode, Meson, Ninja, etc.) instead of "Yet Another Broken Vendor IDE". It's soooo compelling that I personally can run rings around some vendor teams. To be fair--this is NOT limited to Rust. VSCode and its ecosystem enables even C programmers to be stupidly more productive. However, the embedded Rust folks seem to rattle the VSCode folks cage quite a bit more than just plain embedded C folks--this keeps the VSCode guys quite a bit more honest about cross-platform support. 2) Anything RISC-V is in flux, and folks like Bryan Cantrill are leading the charge so the toolchain will be forced to accommodate more than "just C". 3) Even if Rust isn't the answer, you should root for its tooling to break the C hegemony. If Rust finally forces C tooling to acknowledge that "Hey, just maybe we should think about playing nicely in the sandbox and have some useful API's instead of telling everybody to cope or leave because we're the 500lb gorilla.", the successor to Rust will have a vastly easier time.

scoutt 6y ago
See. Not all the problems in embedded are network security risks. If you are evangelizing Rust, please stop trying to lure embedded developers with "networks haxxor buffer overflow" FUD because it's simply not going to work. For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. Edit to add: is not that security bugs are not important, but is not what we (embedded developers) are always chasing or taking away our sleep at night. Embedded is wide enough beyond computer networks. Please take a look at the room around you. Can you count every little chip in there? Including the one in your keyboard, LED lamps, coffee machine? Are all these ARM? NO. Are all these connected to the network? NO. Do you expect them to work 100% of the time without hiccups? YES, and they probably do without you noticing it. And they are probably running 1000s of lines of C. That's embedded.

croh 6y ago

I can understand you. This is the reason, I miss lisp. Why language designers ignore syntax ? Syntax should be CONSISTENT, INTUTIVE and LESS AMBIGUOS (there should be one good way to do thing). As a enduser, I want to focus on solving problem at hand, instead tackling/remembering language syntax/quirks(and new apis). Let me give a very simple example in golang. Function returning single value and function returing multiple values. func foo(x int, y int) int {} func bar(x int, y int) (int, int) {} Even though below synatx works, func bar(x int, y int)(int) {} why there is a additional way to do it by removing parenthesis ? This looks very simple example. But it breaks consistancy of syntax. Adds 2 rules to remember over what saving 2 keystrokes ? In the age of 100x full stack devs, life really sucks.