3 ms·
> nobody took the time to actually do it Because in the end almost nobody actually cares about it enough to create a fix. Small binaries are great, but people
by alpaca128 3y ago
> nobody took the time to actually do it
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.
- flohofwoe 3y agoWhat 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.
- dhruvrajvanshi 3y agoAs 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?