Live data from Hacker News

Making Rust binaries smaller by default

kobzol.github.io

11–20 of 199 posts

Re: Making Rust binaries smaller by default

#11
post #7
post #3

Earlier quoted context omitted.

Yup same. Also I hate the "just strip it" advice. I don't know who on earth strips random binaries and has them actually work fine afterward 100% of the time. Stripping after linking frequently breaks binaries I try it on.

All binaries on a classic Linux distro are stripped (you can use 'file' to quickly check some), so your issues might be worth reporting

Stripped via -s or via strip?

Re: Making Rust binaries smaller by default

#13
post #10
post #4

Initial binary size, like of a hello world, is a great indicator of how much abstraction the language has that youre also paying for. For example, java has to set up a constants pool, parse it from the classfile, run init and cinit, resolve references, allocatea a frame, and so on, just to get to the entrypoint. Compared to C without stdlib which needs to basically just run a few bytes to syscall write(). There are o…

I'm not trying to be rude, but what does your comment have to do with the actual article linked. I suspect you're commenting based solely on the title? If you read the article it mentions 90% reduction if you remove the debug symbols from the rust std lib that get bundled in the final hello world binary. A conversation about Java's size and abstraction is quite irrelevant to the article.

The article talks about how "hello world" binary size can be part of the first impression someone new to your language has. Java is a nice illustration of that. Rust probably isn't, because many of Rust's abstractions are zero-cost, so it's not as obvious a comparison.

Re: Making Rust binaries smaller by default

#14
post #7

Earlier quoted context omitted.

All binaries on a classic Linux distro are stripped (you can use 'file' to quickly check some), so your issues might be worth reporting

Stripped via -s or via strip?

I never understood why strip's "--strip-unneeded" flag wasn't the default. Leaving that out can often enough give you a binary that just doesn't work.

Re: Making Rust binaries smaller by default

#17
post #2

> I can imagine a situation where a seasoned C or C++ programmer wants to try Rust, compiles a small program in release mode, notices the resulting binary size, and then immediately gives up on the language and goes to make fun of it on the forums. While I'm not a seasoned C or C++ programmer I have definitely done this to a few new languages when playing around with them. My thought was "If helloworld.rust is this l…

That’s almost never the case, though. Imagine if a C binary statically linked in libc. Adding a page full of more C to its code would only grow it a tiny amount.

I would hope that it could statically link libc and exclude the unreachable portions.

Re: Making Rust binaries smaller by default

#18
post #16
post #12

[flagged]

Low priority issue easily fixed by googling first if you actually care. And it isn’t like release builds with debug symbols are a bad thing. Getting good bug reports matters, too.

As the article points out, having debug symbols for only the stdlib is not very useful.

Re: Making Rust binaries smaller by default

#19

not a rust programmer. can someone explain why this is in the final binary and not in a shared library?

The Rust compiler statically links everything into a single binary. This can be changed, but is generally discouraged as there are no ABI stability guarantees at this point.

Re: Making Rust binaries smaller by default

#20
post #14

Earlier quoted context omitted.

Stripped via -s or via strip?

I never understood why strip's "--strip-unneeded" flag wasn't the default. Leaving that out can often enough give you a binary that just doesn't work.

Yup that's exactly what I mean. Nobody ever mentions that flag when recommending stripping, and it's frustrating when you realize it's broken. It's been a few years, but even when I finally discovered and tried that flag, it still didn't quite do the right thing. Either it failed to strip stuff that -s stripped, or it still produced a binary that didn't work... I forget what exactly the issue was. I just remember failing to find an alternative to cc -s that was guaranteed to work.
Post reply on HN