# Use cases for \`no\_std\` on tier 1 targets **URL:** \ **Category:** libs\ **Created:** [April 3, 2024, 5:45pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592 "2024-04-03T17:45:04Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [April 3, 2024, 5:45pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/1 "2024-04-03T17:45:04Z")
Hi, does anyone here use `no_std` binaries for targets with a full `std`? I'd love to hear about how `no_std` is being used outside of minimal embedded targets, where you have a well supported (by rust) OS and a specific C runtime environment. E.g. you're using `x86_64-unknown-linux-gnu`, `x86_64-pc-windows-msvc` or `aarch64-apple-darwin` but compile a binary using `#![no_std]` anyway. ---
**Author:** ![afetisov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/afetisov/32/8508_2.png) [@afetisov](https://internals.rust-lang.org/u/afetisov)\ **Post date:** [April 3, 2024, 7:17pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/2 "2024-04-03T19:17:21Z")
One obvious use case is to test that the code works in `#![no_std]` environment. I'm developing on a T1 target, so of course I do any tests and experiments on it as well. ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [April 3, 2024, 7:33pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/3 "2024-04-03T19:33:48Z")
Rust-For-Linux replaces std and alloc with its own non-aborting implementations. ---
**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\ **Post date:** [April 3, 2024, 7:36pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/4 "2024-04-03T19:36:50Z")
Rust-for-Linux uses `no_std` kernel targets (like `*-unknown-none`), and they're actually moving away from their `alloc` fork in the near future too (but still setting `--cfg no_global_oom_handling`). ---
**Author:** ![dvdhrm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dvdhrm/32/3602_2.png) [@dvdhrm](https://internals.rust-lang.org/u/dvdhrm)\ **Post date:** [April 4, 2024, 6:28am UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/5 "2024-04-04T06:28:57Z")
We have several use-cases to avoid `std` on tier1, but they all boil down to avoiding the runtime it enforces (e.g., it installs ELF-ctors for argv capture). For instance, we build custom ELF runtimes, ELF relocators, and dynamic linkers in pure Rust. For those we use `no_std`. Additionally, we have efforts to build strict capability-based runtimes, and these conflict with the global state `std` enforces. The `CloudABI` project was a similar effort, but got discontinued. ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [April 4, 2024, 2:43pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/6 "2024-04-04T14:43:12Z")
This is explicitly a hobby/learning usage, but I have a toy binary built on `x86_64-pc-windows-msvc` which uses `#![no_std]` for the purpose of implementing its own alloc/std functionality directly on top of win32 API. It exists for scratching my "implement your own runtime" itch, and even has a partial `#![no_core]` version. (It's called `notstd`/`notcore` :smile‌:) ---
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [April 8, 2024, 3:11pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/7 "2024-04-08T15:11:32Z")
One thing that came up on Windows is that using `std` automatically adds \>100kb to the binary size mainly due to panic+backtrace+fmt. This matters for people wanting particularly small binaries. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [April 8, 2024, 5:43pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/8 "2024-04-08T17:43:18Z")
> [@chrisd](#): > > This matters for people wanting particularly small binaries. Can you say more about the situations in which those extra bytes are deal-breakers for running on Windows? A fixed cost like that doesn't seem like that big a deal compared to the \*checks\* 30,471,408,390 bytes that my `c:\Windows` folder is using -- it's not like you run `x86_64-pc-windows-msvc` on something with storage measured in MB. ---
**Author:** ![chrisd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisd/32/7232_2.png) [@chrisd](https://internals.rust-lang.org/u/chrisd)\ **Post date:** [April 8, 2024, 6:24pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/9 "2024-04-08T18:24:31Z")
🤷. I'll see if anyone is willing to say more. It's definitely something that's come up a few times now. I doubt the on-disk storage size is the issue though. And there are situations where your Windows will be much smaller than a desktop install (e.g. nanoserver). ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [July 7, 2024, 6:24pm UTC](https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592/10 "2024-07-07T18:24:56Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.