Hello world is large primarily because it statically links in jemalloc and libunwind, which are obviously fixed overhead. Both can be removed (and indeed I would expect jemalloc to be turned off by default sometime soon because each jemalloc release seems to be less stable than the last). If you do this you'll get a much healthier binary size.
C binaries are small because they're assuming you've installed what is ultimately the C runtime on your system (libc).
A direct comparison like that is somewhat comparing apples to oranges. Don't get me wrong, defaults matter, but Rust still does offer the control required to get small binaries, and, those defaults are not nearly as bad for low-level domains where one isn't using the standard library, which is where binary size is most critical. See also https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... and even http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... .
Re:The cost of forsaking C
by Manishearth on Wednesday October 05, 2016 @10:41PM
(#12649814)
Those aren't tricks. Rust does not choose the same defaults as C, and, among other things, statically links to the stdlib and jemalloc.
The tricks you describe are just changing the compile options to those that C uses by default.
on top of that you can apply the same tricks as C; e.g. by running strip, truncating the binary, writing a linker script, etc.
Re:The cost of forsaking C
by steveklabnik on Wednesday October 05, 2016 @12:36PM
(#12645401)
You're not comparing apples and oranges there.
For more: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
(I know there are some "tricks" you can use to make smaller Rust binaries by chopping things out, but of course the same applies to C. For example, I can take the C binary and just truncate the file down to 2230 bytes without breaking it)