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.
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.
Fair points. I wonder what it would look like to have multiple kinds of enforceable crate-level constraints so that everyone doesn't have to take or leave the same "single line"?
> in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding
What about more general libraries that aren't specifically designed for embedded scenarios? It seems like being able to know up-front whether or not those, for example, allocate, would be helpful
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.
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.