4 ms·

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

by 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.
- bcantrill 5y ago
  Wow, what a caustic collection of strawmen. So, I am not a "promoter of a niche language"; I am explaining why a language that many already find compelling is, in my experience, very compelling for our use case. I am not "immediately walking back anything"; I very much stand by everything I said. And I am certainly not saying that Rust is a fit for all use cases. What I am saying is that it's a fit for ours, and that I believe that our use case will be seen by an increasing number of engineers as we see more and more constrained compute elements in more and more places. You clearly disagree, which is fine -- but that doesn't invalidate our experience.
  - ncmncm 5y ago
    Honestly, failing to walk it back is strictly worse. First discovering the world of embedded programming is tremendously exciting. We've all been there. Discovering all these embedded processors in equipment you already own compounds the excitement. But programming "channel processors" goes back to the early '60s, six decades ago. We already know how. We haven't needed Rust. Embedded subsets are also re-invented over and over. That idea hasn't aged so well. In practice, there is no upper limit to the complexity of code you might want to run in a channel processor, so you run into the boundary of your subset early. You often discover you want resource management support, so you link in an embedded RTOS. (OS as library did not originate with Unikernels.) There are many, many free RTOSes, many of them very good. The more POSIXy they are, the less fun and educational they might be.
    - bcantrill 5y ago
      I'm not sure what argument you think I'm making, and I'm even less sure what counterargument you're making (that... no one should implement embedded systems in Rust I guess?). Regardless, it's clear that Rust hits an emotional nerve for you; I'm sorry that you found this talk so agitating!
      - ncmncm 5y ago
        I have already explained at length. You are not obliged to read any of it, and evidently haven't. Repeating it here would be pointless. But, to be clear: 1. There is nothing wrong with Rust, or with coding embedded Rust. 2. Rust brings nothing new to the embedded table, beyond what it does with ordinary programming; 3. non_std has been found by repeated experience over many decades to be a failed idea. I don't like people promoting falsehoods on the internet. Instead of apologizing, just don't!
brundolf 5y ago
Consider this scenario: you're writing some code that needs to run in an environment where some aspect of the standard library isn't an option (allocation, or whatever else) Now you want to pull in a library Does that library work in that constrained environment, or will it break in obvious or subtle ways? In Rust, no_std is a first-class crate attribute. It's enforced inside the crate, and it tells your crate as much when on a dependency. It's impossible (as far as I know) to accidentally use a std crate from your no_std crate, and for a no_std crate to accidentally use something from std internally (or in its dependencies). You can search for a crate on crates.io, and it can have dependencies of its own and dependencies for those dependencies, and you can integrate it all into your project without having to dig into the source code or whatever else to try and find out whether it will fit this set of constraints. That's powerful. In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.
- ncmncm 5y ago
  Or, you link and see what symbols need definitions. As, in fact, everyone already does, and has done for decades. Since no_std would forbid an enormous amount of what you probably also want to use, you probably don't use it. Instead, you see what symbols the linker says need to be defined in your runtime support library, and add those.
- jmull 5y ago
  Thanks... that is what I thought. Honestly, like I mentioned, I don't see that as a particularly useful advantage. The thing is, there is no single line that makes a library suitable for my project, whether it's for a constrained environment or not. I carefully consider many aspects of a library, all from the perspective of what, specifically, my project needs. no_std might be one thing to look for, but I don't know that it's really answering that many of my questions. Also, in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding. So the lack of no_std doesn't seem to be holding non-Rust back. > In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers. I really don't think no_std changes that at all.

by jmull 5y ago

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.
bcantrill 5y ago
Wow, what a caustic collection of strawmen. So, I am not a "promoter of a niche language"; I am explaining why a language that many already find compelling is, in my experience, very compelling for our use case. I am not "immediately walking back anything"; I very much stand by everything I said. And I am certainly not saying that Rust is a fit for all use cases. What I am saying is that it's a fit for ours, and that I believe that our use case will be seen by an increasing number of engineers as we see more and more constrained compute elements in more and more places. You clearly disagree, which is fine -- but that doesn't invalidate our experience.
- ncmncm 5y ago
  Honestly, failing to walk it back is strictly worse. First discovering the world of embedded programming is tremendously exciting. We've all been there. Discovering all these embedded processors in equipment you already own compounds the excitement. But programming "channel processors" goes back to the early '60s, six decades ago. We already know how. We haven't needed Rust. Embedded subsets are also re-invented over and over. That idea hasn't aged so well. In practice, there is no upper limit to the complexity of code you might want to run in a channel processor, so you run into the boundary of your subset early. You often discover you want resource management support, so you link in an embedded RTOS. (OS as library did not originate with Unikernels.) There are many, many free RTOSes, many of them very good. The more POSIXy they are, the less fun and educational they might be.
  - bcantrill 5y ago
    I'm not sure what argument you think I'm making, and I'm even less sure what counterargument you're making (that... no one should implement embedded systems in Rust I guess?). Regardless, it's clear that Rust hits an emotional nerve for you; I'm sorry that you found this talk so agitating!
    - ncmncm 5y ago
      I have already explained at length. You are not obliged to read any of it, and evidently haven't. Repeating it here would be pointless. But, to be clear: 1. There is nothing wrong with Rust, or with coding embedded Rust. 2. Rust brings nothing new to the embedded table, beyond what it does with ordinary programming; 3. non_std has been found by repeated experience over many decades to be a failed idea. I don't like people promoting falsehoods on the internet. Instead of apologizing, just don't!

brundolf 5y ago

Consider this scenario: you're writing some code that needs to run in an environment where some aspect of the standard library isn't an option (allocation, or whatever else) Now you want to pull in a library Does that library work in that constrained environment, or will it break in obvious or subtle ways? In Rust, no_std is a first-class crate attribute. It's enforced inside the crate, and it tells your crate as much when on a dependency. It's impossible (as far as I know) to accidentally use a std crate from your no_std crate, and for a no_std crate to accidentally use something from std internally (or in its dependencies). You can search for a crate on crates.io, and it can have dependencies of its own and dependencies for those dependencies, and you can integrate it all into your project without having to dig into the source code or whatever else to try and find out whether it will fit this set of constraints. That's powerful. In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.

ncmncm 5y ago
Or, you link and see what symbols need definitions. As, in fact, everyone already does, and has done for decades. Since no_std would forbid an enormous amount of what you probably also want to use, you probably don't use it. Instead, you see what symbols the linker says need to be defined in your runtime support library, and add those.
jmull 5y ago
Thanks... that is what I thought. Honestly, like I mentioned, I don't see that as a particularly useful advantage. The thing is, there is no single line that makes a library suitable for my project, whether it's for a constrained environment or not. I carefully consider many aspects of a library, all from the perspective of what, specifically, my project needs. no_std might be one thing to look for, but I don't know that it's really answering that many of my questions. Also, in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding. So the lack of no_std doesn't seem to be holding non-Rust back. > In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers. I really don't think no_std changes that at all.