4 ms·

> I doubt that we'll see it used for low-power/resource-constrained firmware I'm curious what your reasoning is for saying this?

zozbot234 7y ago
Are you going to use Rust on a PIC12 with 32 bytes of data memory and max 256 code instructions? Of course not. Assembly is still king in this low-powered embedded class and will stay as such for the foreseeable future.
- brohee 7y ago
  At the 10 year horizon the grandparent was using, the ultra low end of MCU may be substantially more powerful, with possibly lowend AM or RISC V being the smallest thing you can find. At some point, packaging will dominate cost over silicon for such small MCU so a better silicon won't cost much more...
  - zozbot234 7y ago
    Packaging will dominate silicon costs? I see plenty of silicon chips directly soldered onto PCB's for the smallest and cheapest applications, i.e. no packaging whatsoever.
    - brohee 7y ago
      The entity that solders it received it on a tape most likely, in 10 year I can totally see a small 32 bit core costing less that that.
- wtetzner 7y ago
  Maybe I misread it, but it sounded like the OP was comparing Rust to C or C++ on low-powered/resource-contrained firmware, not assembly.
- derefr 7y ago
  In that specific case, I’d probably still not use ASM directly, but rather probably a Lisp DSL for machine-code generation (and a Lisp emulator for the ISA it generates), so that I could in turn write some genetic algorithm or somesuch to explore the space of such ASTs (and thereby the space of max-256-byte machine-code programs) to find the optimal way to pack instructions to solve my problem (where “solve my problem” is specified in terms of what the emulator’s registers and memory should look like on a given cycle.) ASM is for the use-case where you're optimizing code in terms of using specific instructions or intrinsics; but it's not really for the case where you're concerned with specific opcode encodings (as ASM abstracts that away, grouping multiple different opcode encodings—some short, some very long—behind a single friendly instruction name.) In that case, you have to work with the machine-code directly—or, at least, through data structures that contain machine-code at the base level, and so can tell you exactly what machine-code they contain.
- jack_h 7y ago
  But the full quote is: "I doubt that we'll see it used for low-power/resource-constrained firmware, but lots and lots of embedded systems are now bulky Linux boxes with years of uptime, and I can see Rust making inroads there." There is a massive number of devices between an 8-bit PIC and a Cortex-A. Obviously you're not going to use Rust on a tiny PIC or similar, hell that architecture is outwardly hostile towards even C. I'm guessing these very low power chips will exist for many years to come, but a lot of work has moved over to things like Cortex-Ms which absolutely benefit from things like Rust.
  - jononor 7y ago
    Yeah, this segment (Cortex-M) is on the order of a billion devices shipped each year. With growth expected to stay high for years to come. Plenty of space for Rust to get adopted.
- dorfsmay 7y ago
  I interpreted alxlaz' comment as Rust vs C (or other high level language, C+" etc...), which his answer to my question seem to indicate that was the case, as he gives more reason for Rust likely not to be adopted on some platforms.
alxlaz 7y ago
It's mostly a hunch, based on a combination of lots and lots of factors. It's very difficult to explain. From a distance, "embedded" looks like a very homogenous field, but it's nothing like that. Some of the factors that contribute to this hunch -- but bear in mind that they don't apply everywhere in the embedded development space, nor equally, nor to every kind of device -- include: 1. A lot of resource-constrained firmware is so straightforward that Rust's benefits simply don't justify the effort of learning it and using it. In turn, without sufficient demand, there isn't much motivation for large tooling vendors to get into the game. Without the large tooling vendors, the kind of companies whose money could shift the landscape significantly won't get in the game, either. 2. Lots of embedded software development is outsourced. The margins are pretty small, and the companies in this field are both unwilling and unable to build technical expertise early on, so there's a lot of inertia. 3. Lots of embedded software is developed based on manufacturer-supplied SDKs. Manufacturers in this field tend to run high-inertia, cost-conscious software teams that take a long time to catch up with the rest of the software industry. 4. A lot of this inertia is mistaken for prudence ("we value stability", "we don't just jump on the hype train") and touted as a positive thing. That's why IoT security is what it is, for example (and it's not just IoT, and not just security. Lots of areas in the embedded space suffer from terrible practices). This is an industry where an embarrassingly large number of companies are just discovering continuous integration. A whole new programming language won't just happen overnight. 5. Lots of resource-constrained firmware is written with pretty strenuous regulatory constraints in place, under considerable pressure from internal standards, audits and so on. In some regards, Rust's tooling ecosystem still needs to grow and mature. AFAIK there's no serious equivalent to Coverity, for example -- and plenty of companies value it not just for the analysis it makes (which doesn't mean as much as it seems because the Rust compiler does a lot of static analysis on its own), but also for the kind of traceability and integration that it gives them, and the ability to implement the kind of internal processes that look good on paper during an audit. It's a mix of legitimate and non-legitimate concerns (specifically, #5 is very legitimate -- lots of internal processes are just software safety theater, but many aren't).
- lostdog 7y ago
  Very interesting breakdown. Do you think that Rust could instead help outsourcing? Similar to how Java's GC keeps teams away from segfaults, could Rust's safety guarantees give companies more confidence that an outsourced team's code would have fewer critical bugs?

zozbot234 7y ago

Are you going to use Rust on a PIC12 with 32 bytes of data memory and max 256 code instructions? Of course not. Assembly is still king in this low-powered embedded class and will stay as such for the foreseeable future.

brohee 7y ago
At the 10 year horizon the grandparent was using, the ultra low end of MCU may be substantially more powerful, with possibly lowend AM or RISC V being the smallest thing you can find. At some point, packaging will dominate cost over silicon for such small MCU so a better silicon won't cost much more...
- zozbot234 7y ago
  Packaging will dominate silicon costs? I see plenty of silicon chips directly soldered onto PCB's for the smallest and cheapest applications, i.e. no packaging whatsoever.
  - brohee 7y ago
    The entity that solders it received it on a tape most likely, in 10 year I can totally see a small 32 bit core costing less that that.
wtetzner 7y ago
Maybe I misread it, but it sounded like the OP was comparing Rust to C or C++ on low-powered/resource-contrained firmware, not assembly.
derefr 7y ago
In that specific case, I’d probably still not use ASM directly, but rather probably a Lisp DSL for machine-code generation (and a Lisp emulator for the ISA it generates), so that I could in turn write some genetic algorithm or somesuch to explore the space of such ASTs (and thereby the space of max-256-byte machine-code programs) to find the optimal way to pack instructions to solve my problem (where “solve my problem” is specified in terms of what the emulator’s registers and memory should look like on a given cycle.) ASM is for the use-case where you're optimizing code in terms of using specific instructions or intrinsics; but it's not really for the case where you're concerned with specific opcode encodings (as ASM abstracts that away, grouping multiple different opcode encodings—some short, some very long—behind a single friendly instruction name.) In that case, you have to work with the machine-code directly—or, at least, through data structures that contain machine-code at the base level, and so can tell you exactly what machine-code they contain.
jack_h 7y ago
But the full quote is: "I doubt that we'll see it used for low-power/resource-constrained firmware, but lots and lots of embedded systems are now bulky Linux boxes with years of uptime, and I can see Rust making inroads there." There is a massive number of devices between an 8-bit PIC and a Cortex-A. Obviously you're not going to use Rust on a tiny PIC or similar, hell that architecture is outwardly hostile towards even C. I'm guessing these very low power chips will exist for many years to come, but a lot of work has moved over to things like Cortex-Ms which absolutely benefit from things like Rust.
- jononor 7y ago
  Yeah, this segment (Cortex-M) is on the order of a billion devices shipped each year. With growth expected to stay high for years to come. Plenty of space for Rust to get adopted.
dorfsmay 7y ago
I interpreted alxlaz' comment as Rust vs C (or other high level language, C+" etc...), which his answer to my question seem to indicate that was the case, as he gives more reason for Rust likely not to be adopted on some platforms.

alxlaz 7y ago

It's mostly a hunch, based on a combination of lots and lots of factors. It's very difficult to explain. From a distance, "embedded" looks like a very homogenous field, but it's nothing like that. Some of the factors that contribute to this hunch -- but bear in mind that they don't apply everywhere in the embedded development space, nor equally, nor to every kind of device -- include: 1. A lot of resource-constrained firmware is so straightforward that Rust's benefits simply don't justify the effort of learning it and using it. In turn, without sufficient demand, there isn't much motivation for large tooling vendors to get into the game. Without the large tooling vendors, the kind of companies whose money could shift the landscape significantly won't get in the game, either. 2. Lots of embedded software development is outsourced. The margins are pretty small, and the companies in this field are both unwilling and unable to build technical expertise early on, so there's a lot of inertia. 3. Lots of embedded software is developed based on manufacturer-supplied SDKs. Manufacturers in this field tend to run high-inertia, cost-conscious software teams that take a long time to catch up with the rest of the software industry. 4. A lot of this inertia is mistaken for prudence ("we value stability", "we don't just jump on the hype train") and touted as a positive thing. That's why IoT security is what it is, for example (and it's not just IoT, and not just security. Lots of areas in the embedded space suffer from terrible practices). This is an industry where an embarrassingly large number of companies are just discovering continuous integration. A whole new programming language won't just happen overnight. 5. Lots of resource-constrained firmware is written with pretty strenuous regulatory constraints in place, under considerable pressure from internal standards, audits and so on. In some regards, Rust's tooling ecosystem still needs to grow and mature. AFAIK there's no serious equivalent to Coverity, for example -- and plenty of companies value it not just for the analysis it makes (which doesn't mean as much as it seems because the Rust compiler does a lot of static analysis on its own), but also for the kind of traceability and integration that it gives them, and the ability to implement the kind of internal processes that look good on paper during an audit. It's a mix of legitimate and non-legitimate concerns (specifically, #5 is very legitimate -- lots of internal processes are just software safety theater, but many aren't).

lostdog 7y ago
Very interesting breakdown. Do you think that Rust could instead help outsourcing? Similar to how Java's GC keeps teams away from segfaults, could Rust's safety guarantees give companies more confidence that an outsourced team's code would have fewer critical bugs?