4 ms·

> Of course none of the other languages have "no_std", and don't need it. Your Rust code doesn't need it either. Don't want to use library features? Just don't

> Of course none of the other languages have "no_std", and don't need it. Your Rust code doesn't need it either. Don't want to use library features? Just don't use them. 1) no_std allows composability. One of Rust's biggest strengths is its package ecosystem, and I imagine this will only become more true in the increasingly "weird" and sprawling hardware ecosystem described by the OP, where the ability to re-use code that other people might have written for your hardware could save you from having to "solder in a JTAG connector and reverse-engineer the code in there to figure out how your code can operate in the environment". "Just don't use [the standard library]" doesn't work when you want to use third-party libraries. 2) no_std's static checks are nice even in your own code. The value of static analysis has been argued about so many times in threads like these that I don't feel like re-treading that ground. But suffice to say: it's clear some people think they can write flawless code and don't see the benefits of assistance, but plenty of others know their limitations and benefit from static analysis. 3) Rust seems to have straddled an interesting and useful line in terms of which features are available in these limited contexts and which ones aren't, giving you as much to work with as possible. And thanks to #1 and #2 you can use those features fearlessly; you never have to guess about whether or not they're in the "safe" category. Hygenic macros in particular can act as a compile-time force-multiplier when you want better abstractions but don't want to (or can't afford to) do extra things at runtime. As always comes up in these discussions: yes, you can technically cover this usecase with C and C++. You can technically cover it with raw assembly code, or binary strings, or a pair of wires. Don't discount ease-of-use as a factor that can take things from "technically possible but practically infeasible" to "doable and worth doing".

ncmncm 5y ago
> "you can technically cover this usecase" Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. It would be more meaningful to say you can technically do it in Rust, because it is possible in principle to do it, even though practically nobody ever has, and vanishingly few ever will. Everyone who makes up an "embedded subset" congratulates themselves for identifying just the right subset. Then they immediately start moving other stuff over the line. And never stop. This is all familiar ground. All that is new is new people noticing it. An embedded program in any language that relies on a library function not implemented in its runtime environment will, in any case, fail to link. That is static checking. Rust is not doing more static checking here. It is just doing it sooner, and forbidding a truly enormous amount of what would also be useful to embedded programs. Most of us would rather have access to all of that, and let the linker identify what support is needed for what is used.
- brundolf 5y ago
  > essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. When has "essentially all...today" ever placed a limitation on future progress?
  - ncmncm 5y ago
    Not the point. Saying something is only "technically" possible when in fact it is already done in billions of devices is to suggest an absurdity.
- tialaramex 5y ago
  > Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. How about you break "essentially all" down between these two different languages? You must have good statistics on this, to have such confidence to say "essentially all" here, and yet for some reason you lump together C and C++ as if they're the same when you know they aren't. Might it in fact also have been true to say "essentially all" are C? > Most of us would rather have access to all of that, Which notable embedded systems did you program ncmncm? Or is "us" here based on a survey you can point us to about other embedded systems programmers who actually have practical experience?
  - ncmncm 5y ago
    If you knew of a language other than C or C++ used for any substantial fraction (say, more than 0.1%) of peripheral device designs, I am confident you would have cited it.
    - tialaramex 5y ago
      If we're just guessing here then I'd guess there'd be some considerable fraction of Assembler. Especially when you're very constrained. If your total code footprint is 16 kilobytes, suddenly it doesn't seem daunting to think about the actual hardware instructions - there's only a few thousand of them after all. But people also seem to be merrily using special-purpose high level languages for their domain e.g. P4. What I couldn't find much of was C++. If you had numbers we'd be looking at them, right?
jmull 5y ago
I'm not sure I'm understanding this correctly... Rust libraries are generally composable, so that's not what makes no_std interesting. I guess the advantage is that it sets a bar that means "can run in a wide range of environments" and it's a standard bar so that everything that's "no_std" can (more or less) run in the same wide range of environments. But I don't know. A standard bar is nice, but I'm not sure it's really that much of a help. I just dabble with embedded programming as a hobby, but it doesn't seem to me like non-Rust approaches (I'm thinking of C and Python) are suffering from a lack of composability.
- ncmncm 5y ago
  The speaker does what many promoters of niche languages do: picks out a named feature and insists that it makes possible what other languages don't. It is immediately walked back to "makes feasible", and shortly "makes more convenient", before dissolving in meaninglessness. I don't think Rust needs or benefits from that kind of promotion. It's a pretty good language that will get usable in more places as it matures. Overpromoting it into places it is not mature enough for yet causes problems. Is Rust mature enough for embedded use? In some places, certainly. In all places? Certainly not.
  - brundolf 5y ago
    Making enough easy things "more convenient" can make harder things "feasible", which can lead to virtually-impossible things becoming realistically-possible. You've intentionally taken mine and others' words in the most uncharitable ways possible and you've displayed a general willingness to make this an unproductive discussion, so I'm going to stop engaging with you now.
    - ncmncm 5y ago
      I would be happy not to contradict you if you were to post comments that do not express absurdities. Rust the language and Rust the community do not benefit from people posting transparent falsehoods. There is plenty of substance to Rust. It doesn't need puffing.
  - 5y ago

ncmncm 5y ago

> "you can technically cover this usecase" Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. It would be more meaningful to say you can technically do it in Rust, because it is possible in principle to do it, even though practically nobody ever has, and vanishingly few ever will. Everyone who makes up an "embedded subset" congratulates themselves for identifying just the right subset. Then they immediately start moving other stuff over the line. And never stop. This is all familiar ground. All that is new is new people noticing it. An embedded program in any language that relies on a library function not implemented in its runtime environment will, in any case, fail to link. That is static checking. Rust is not doing more static checking here. It is just doing it sooner, and forbidding a truly enormous amount of what would also be useful to embedded programs. Most of us would rather have access to all of that, and let the linker identify what support is needed for what is used.

brundolf 5y ago
> essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. When has "essentially all...today" ever placed a limitation on future progress?
- ncmncm 5y ago
  Not the point. Saying something is only "technically" possible when in fact it is already done in billions of devices is to suggest an absurdity.
tialaramex 5y ago
> Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code. How about you break "essentially all" down between these two different languages? You must have good statistics on this, to have such confidence to say "essentially all" here, and yet for some reason you lump together C and C++ as if they're the same when you know they aren't. Might it in fact also have been true to say "essentially all" are C? > Most of us would rather have access to all of that, Which notable embedded systems did you program ncmncm? Or is "us" here based on a survey you can point us to about other embedded systems programmers who actually have practical experience?
- ncmncm 5y ago
  If you knew of a language other than C or C++ used for any substantial fraction (say, more than 0.1%) of peripheral device designs, I am confident you would have cited it.
  - tialaramex 5y ago
    If we're just guessing here then I'd guess there'd be some considerable fraction of Assembler. Especially when you're very constrained. If your total code footprint is 16 kilobytes, suddenly it doesn't seem daunting to think about the actual hardware instructions - there's only a few thousand of them after all. But people also seem to be merrily using special-purpose high level languages for their domain e.g. P4. What I couldn't find much of was C++. If you had numbers we'd be looking at them, right?

jmull 5y ago

I'm not sure I'm understanding this correctly... Rust libraries are generally composable, so that's not what makes no_std interesting. I guess the advantage is that it sets a bar that means "can run in a wide range of environments" and it's a standard bar so that everything that's "no_std" can (more or less) run in the same wide range of environments. But I don't know. A standard bar is nice, but I'm not sure it's really that much of a help. I just dabble with embedded programming as a hobby, but it doesn't seem to me like non-Rust approaches (I'm thinking of C and Python) are suffering from a lack of composability.

ncmncm 5y ago
The speaker does what many promoters of niche languages do: picks out a named feature and insists that it makes possible what other languages don't. It is immediately walked back to "makes feasible", and shortly "makes more convenient", before dissolving in meaninglessness. I don't think Rust needs or benefits from that kind of promotion. It's a pretty good language that will get usable in more places as it matures. Overpromoting it into places it is not mature enough for yet causes problems. Is Rust mature enough for embedded use? In some places, certainly. In all places? Certainly not.
- brundolf 5y ago
  Making enough easy things "more convenient" can make harder things "feasible", which can lead to virtually-impossible things becoming realistically-possible. You've intentionally taken mine and others' words in the most uncharitable ways possible and you've displayed a general willingness to make this an unproductive discussion, so I'm going to stop engaging with you now.
  - ncmncm 5y ago
    I would be happy not to contradict you if you were to post comments that do not express absurdities. Rust the language and Rust the community do not benefit from people posting transparent falsehoods. There is plenty of substance to Rust. It doesn't need puffing.
- 5y ago