My Idea to buff no_std

[t4ce]

Hello People

i don't have the immediate need for this but maybe some time in the future such a concept may be useful do somebody, maybe.

However i am still very interested in what the other souls think towards this Idea:

#![no_std_fs]

extending the classic Version to the cleanest small subset or breakdown that is harmonic to how no_std works.

#![no_std_fs] #![no_std_net] #![no_std_time] #![no_std_env] #![no_std_process]

Because no_std is such "Hammer" that i saw only very few people resort to it and usually there is always like some gradient to the tool-age available, wherever really i have seen solutions, there was some Options to it.

Thank you and have a nice evening,

Jonas

[chrefr]

@t4ce

't have the immediate need for this but maybe some time in the future such a concept may be useful do somebody, maybe.

We don't introduce features just because we think they're cool. The "Motivation" section is the most important in the RFC template.

That being said, what will this give? Almost all targets either have operating systems and then they have everything, or they don't and then they have nothing, and if they have something it's in special drivers and not the job of std. The only exceptions I know are non-WASI WASM (that pretends to have std but mocks most function), and UEFI which is a strange target.

[t4ce]

Proposal to add "features" to standard library

Proposal to add "features" to standard library Goal After mastering Rust in smaller and bigger hobby projects, I wanted to use Rust in production. But my boss asked me about the danger of "supply chain attacks" in Rust. Sadly, the Rust crate ecosystem is "potentially very dangerous". I didn't have any bad experience till now, but the doors are widely open for malevolent actors! It is enough to get a ransomware attack only once to make life miserable and to destroy the reputation of the Rust crat…

I found that we had a long time ago, a proposal here in the Forum. He elaborated that way better from the get-go.

Suppose I have a parser/codec/algorithm library! Uses are Vec, String, HashMap, Arc and more, so making it no_std buys me very little and imposes quite a bit of work.

Rust Reference itself describes no_std as useful when the platform lacks std, as well as when code is purposefully not using capabilities of the standard library, explicitly mentioning FS and NET.

And if you for example decide, to build a system or structure a system, you would have milestones to lift and would never forget about where you would need to not have that particular STD in, to me that's way more important to maintain then reexport std or other hacks.

STD is perhaps a nice flat baseline but usually no_std lets me reject the entire opaque platform abstraction; I want a way to reject individual opaque parts of it. After all i have absolutely no clue without reading eventually into source-code that i don't even have available. So i don't know whats going on and i just wants to partly contain that:

Because i cant believe you on the point that there is Everything or Nothing, that is what we have right now, with the contemporary no_std solution that should be perhaps reshaped.

1. A platform having FS/NET/process support does not mean every crate should be allowed to silently grow those dependencies, for example there would be no unexpected execution in some part of FS where you would not expect that. Okay just because the Idea maps to Itself does not make it that better but:

2. no_std is too coarse when the real invariant is only “this layer must never touch the filesystem/network/environment.” There is not all or nothing, i have seen plenty Platforms that have STD for File systems but just no sense of Network, after all Rust is as well for Low-Level Hardware and Driver development.

3. Compiler-enforced partial std boundaries turn architecture from documentation into something CI can actually preserve for years. We would never regress a Library with that on top.

4. Without that, one innocent std::fs::read, std::env::var, SystemTime::now, or Command::new can quietly collapse a boundary nobody remembered was supposed to exist. And That is my main point about it, that the no_std is so great in how it can achieve the no_std assumptions that i just would assume that we can as well just consider: I love the Path where as env is just not supported with all the assumptions jet.

After all, as soon as you stack 1 Layer on top of your completely fine std Abi platform code, suddenly you realise that it can not do it as "expected" and there you have the hidden STD contract: One does not simply "std".

Thank you for that perspective or yours, that is what i believe it will give.

[chrefr]

@t4ce

Rust Reference itself describes no_std as useful when the platform lacks std, as well as when code is purposefully not using capabilities of the standard library, explicitly mentioning FS and NET.

I'm pretty sure you misread the reference. It does say this, but I'm pretty sure the meaning is not "a crate which wants to guarantee it won't use std by mistake" (why will it want that? Furthermore it's not really a guardrail as it's too easy to import a std-using dependency by mistake), but for a crate that does not need the capabilities of std, and wants to be available to no_std users. That is, the reference reads: use no_std either if you must use it (your target doesn't support std), or you don't need it and wants to support users that can't use it.

@t4ce

Suppose I have a parser/codec/algorithm library! Uses are Vec, String, HashMap, Arc and more, so making it no_std buys me very little and imposes quite a bit of work.

A (non-IO-performing) parser/codec/algorithm is actually a perfect case for no_std. From all items you listed, only HashMap is not available with core + alloc, and that is due to an implementation limitation that we hope will be lifted in the future.