It's not a great sign that this bug existed for 7 years, people noticed, asked about it, wrote tickets, everybody agreed that it should be fixed but then nobody took the time to actually do it (and the eventual fix is a rather crude hack by just stripping the output binary instead of preventing that debug symbols slip into a release binary in the first place).
Looks more like a systemic issue in the Rust development process to me tbh.
What's more shocking though is that even after a 90% size reduction, a vanilla hello world is still 415 KBytes. That's about 10..100x bigger than I would expect from a low level "systems programming language".
A vast majority of that 415 KB is due to the backtrace support, which is amazingly complicated. (See my other comment for specifics.) It will depend on some more machinaries from std, and a "simple" hello world can always panic if stdout is closed or so, therefore that part of std cannot be easily removed unless you are fine with useless backtraces.
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).
For a statically linked libc I would expect that only the stdlib code that's actually used is included in the program (even without LTO).
For instance a statically linked C hello world for Linux via MUSL (cross-compiled with `zig cc -Os -target x86_64-linux-musl hello.c -o hello` because I'm currently on a Mac) is just 5 KBytes.
Musl doesn't have anything like Rust backtraces so it's not a fair comparison. By the way, glibc does have one [1], and I would be surprised if adding a backtrace printer doesn't significantly increase the binary size.
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.
What bothers me more than the actual binary size (yes ok, the remaining 400 KBytes may actually be justified as pointed out by @lifthrasiir) is that the additional 3.5 MBytes baggage of stdlib debug info was just dead weight. They could just as well have included 3.5 MBytes of noise in each executable.
As pointed out by the author, people who care could already strip the debug info.
C was created in a time when binary sizes used to be important for every program. These days, it only matters for a small subset of use cases.
If anything, the fact that no one fixed it for this long is an indicator that it doesn't matter much for the kinds of things people typically build with rust.
It's nice that there's a fix now, but would I care if Firefox or Chrome binary was 4MB bigger?
If you read the article you would know that this is just about changing defaults. You already could achieve this by editing your project's Cargo.toml. As is documented and discussed in several places over the years (google "shrink rust binary size").
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.
If people only pick "interesting" problems to work on and ignore fundamental (but boring) issues like this, then those issues will just pile up and frustration and burnout will grow even more in the long run. At some point you'll have to stop feature development for a while and put all hands on cleaning up the accumulated cruft.
The issue was initially filed in 2017, but was partially solved by the introduction of `strip = true` in 2020 (nightly) or 2022 (stable). The OP wrote a concrete and comperhensive proposal to fully solve the issue in late 2023. Unlike your claim, people did periodically revisit this issue and even largely solve it.
This is not a fundamental issue, it's just a kind of boring papercut that Rust has many examples of. If you need to do a whole lot of "foundational" yak shaving to ultimately accomplish something else that's clearly worthwhile, the Rust folks are quite comfortable with that: it's what the WG's and initiatives are for.
