A very relevant example is `build-std`, which builds the standard library (and does LTO) instead of copying a pre-built one. This feature has been on nightly for at least a couple of years.

Are you saying that 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"?

The Cargo doc page on `build-std` says that it is an "unstable feature" which will only eventually end up in stable once it is stabilized: https://doc.rust-lang.org/cargo/reference/unstable.html#buil... and Kobzol's linked post above indicates that `build-std` is "sadly still unstable."

Reducing the binary size is usually more important than performance (and often more important than memory safety, if we are totally honest...).

Personally, I hate bloated software just as much as slow software. It's crazy what you can do with 64 kilobytes, let the demoscene blow your mind: https://www.youtube.com/watch?v=ZfuierUvx1A

Would be awesome if compilers could do the same :)

Over in C, plenty of people work on things where file size matters. It is a big deal. System constraints (embedded) wire constraints (far away systems where internet is slow and ephemeral), legacy systems where everything is going to be slow even moving that fat file around and you have to be present to update (ATM, ticket, vending machines)... The list goes on.

So it may NOT matter for the desk top, or mobile or servers, but that's a tiny fraction of the computing out there.

If we talk about ultra-low-power platforms, e.g. energy-harvesting IoT devices, 1MB is still quite a lot.

If we are going to argue that Rust can compete with C/C++, it needs to have similar performance, also regarding binary size.

Never had the time or dedication to actually verify this but I've been bitten by programs and OS-es that trash the cache too much and I've seen humanly perceivable lags because of it. But maybe in this case I am overreacting.

I think that it depends on what sort of machine you're aiming for the binary to run on. I develop for a few platforms where a 1MB executable size would be completely unacceptable.

I know floats are full of scary corner cases, but… Assuming tens of bytes per an if statement, hundreds of corner cases just in formatting? Is it really that bad?

See issue #13871

https://github.com/rust-lang/rust/issues/13871

I exaggerate, point is that we've come a long way and are still getting better. Different people look at different metrics and the more popular the language becomes the bigger the variety of metrics the come into focus.

    #include <stdio.h>
    #include <stdlib.h>
    #include <execinfo.h>
    #include <errno.h>
    
    void print_backtrace(void) {
        void *traces[50];
        char **symbols;
        int num_traces, i;
    
        num_traces = backtrace(traces, sizeof(traces) / sizeof(*traces));
        strings = backtrace_symbols(traces, num_traces);
        if (!strings) return;
        for (i = 0; i < num_traces; ++i) {
            fprintf("%d: %s\n", i + 1, strings[i]);
        }
        free(strings);
    }
    
    int main(void) {
        static const char FMT[] = "Hello, World!\n";
        static int EXPECTED = (int) (sizeof(FMT) - 1);
        int ret = printf(FMT);
        if (ret < 0) {
            fprintf(stderr, "printf failed: %s\n", strerror(errno));
            print_backtrace();
            return 1;
        }
        if (ret != EXPECTED) {
            fprintf(stderr, "printf failed: only %d characters were written\n", ret);
            print_backtrace();
            return 1;
        }
        return 0;
    }

    $ gcc -Os a.c && ls -al a.out && size
    -rwxr-xr-x 1 user user 15952 Jan 24 17:49 a.out
       text    data     bss     dec     hex filename
       1316     584       8    1908     774 a.out
    $ gcc -s -Os a.c && ls -al a.out && size
    -rwxr-xr-x 1 user user 14472 Jan 24 17:50 a.out
       text    data     bss     dec     hex filename
       1316     584       8    1908     774 a.out
    $ gcc -s -Os -fuse-ld=lld a.c && ls -al a.out && size
    -rwxr-xr-x 1 user user 4552 Jan 24 17:50 a.out
       text    data     bss     dec     hex filename
       1199     528       1    1728     6c0 a.out

    zig cc -Os -target x86_64-linux-musl hello.c -o hello

https://github.com/llvm/llvm-project/commit/36f01909a0e29c10...

And naturally we already have a port: https://crates.io/crates/debuginfod-rs

Also, Rust has no direct platform support unlike C. So everything has to be statically linked to be portable. A statically linked glibc is indeed much larger than that (~800 KB in my machine). Conversely, you can sacrifice portability and link to `libstd*.so` dynamically to get a very small binary (~17 KB in my machine, both for C and Rust).

Because in the end almost nobody actually cares about it enough to create a fix.

Small binaries are great, but people care mainly about how fast it compiles and how fast it runs, and in the few cases where the binary size is important it was already possible to shrink it significantly (more than with this new change). In my entire life I have never heard a user complain about the size of the binary, what people really care about is efficiency/speed at runtime. That's why people regularly mention VS Code using Electron, but not that its installation package alone has >500MB.

The `strip` was added to rust nightly in 2020.

1: https://github.com/johnthagen/min-sized-rust

2: https://kerkour.com/optimize-rust-binary-size

3: https://rustrepo.com/repo/johnthagen-min-sized-rust

4: https://sing.stanford.edu/site/publications/rust-lctes22.pdf

5: https://arusahni.net/blog/2020/03/optimizing-rust-binary-siz...

That happens all the time, it's called prioritizing. If you don't let people prioritize, they will burn out and leave the project. That's not what you want.