Binary size violates the you-do-not-pay-for-what-you-do-not-use principle.

[typeless]

I am evaluating a use case of Rust on an embedded system after playing with it occasionally as hobby. We currently use Go for it and it works great. However, we have to adopt a 'busybox'-like approach to deal with the binary size problem as the number of our small CLI tools growing.

I tried Rust but the outcome regarding binary size was disappointing. A hello-world program with a single dependency (clap) resulted in a 5.x MB executable, which has been already more monstrous than the aforementioned Go application we developed. And the Go executable doesn't even link to any shared library.

I am aware of the 'tricks' found by someone and the blog posts that help with the problem, but it works only for the Nightly, which isn't a good sign for uses in production software. And most importantly, the small binary should be the default for release builds and users only pay for the binary size bloating if the "additional" features are actually utilized.

Not sure If this is a realistic demand to Rust. Hopefully we don't have to stick to C forever when binary size matters.

[hanna-kruppe]

It's hard to tell at a distance if the bloat is only due to jemalloc being used by default (and requiring nightly to opt out), or if there are other factors at play too. But at least for the jemalloc issue, there are plans to make the system allocator the default, see #36963 — unfortunately currently stalled.

[steveklabnik]

Hi @typeless !

We care about this issue, but we also try to keep the bug tracker for specific, actionable bugs. All of those things relating to binary size (including the unstable bits) already have issues open. As such, I'm going to give this one a close. General discussions about developing Rust should happen on https://internals.rust-lang.org/. Thank you!