scapegoat VS min-sized-rust

Agreed, switching to tinyvec (2.X, breaking) and per-instance storage size (1.X, non-breaking) are currently open issues.

This crate is #[forbid(unsafe_code)]. A future version will also have all dependencies be #[forbid(unsafe_code)]. Safety bugs in the standard library may or may not be found in the future (there have been CVEs in the past).

Tried to evaluate memory footprint, in terms of executable code bytes stored in the .text section, please see the writeup here.

Woah that made a huge difference! Thanks for taking the time to try that out and type it up. Was able to retrace your steps and get the same 8.4KB result. I've updated the writeup again.

This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust

This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind...

The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded development it’s definitely important, but for most use cases, does it matter?

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30

Are you saying that at that point the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every resulting binary.

I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't rake Rust seriously because of that. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berate and ignore Rust on that basis alone (so the author is quite right to call this out as a factor).

Looking at the https://github.com/johnthagen/min-sized-rust repo, final binary size of 51 KB when compilation / linking / stripping takes stdlib into account (and not just blindly copy-pasting the 4MB binary blob) is acceptable and much more reasonable. I wouldn't care for further micro-optimizations e.g. going to 20KB or even 5KB (further down the README file).

I also don't use nightly in my Rust work so I guess I'll have to wait several more years. :(

My go to reference when I want to reduce rust binary size is the excellent https://github.com/johnthagen/min-sized-rust, a set of guidelines on how to reduce size with explanations of the consequences

Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust. By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.

This is not quite what you're asking, but it does also address the underlying concern: https://github.com/johnthagen/min-sized-rust

And what about the binary size? Applying some cheats found in the Unofficial Bevy Cheat Book and in the Minimizing Rust Binary Size article I’ve achieved to fit the whole wasm binary in less than 10M, which become 2.8M when gzip compressed.

Rust binaries are so huge because the default settings turn off most size optimizations to reduce compile times. Read through this page.