Hacker News Reader

Comment by Humphrey | Hacker News Reader

> 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 large, it'll be huge once I've actually written more code".

View on HN

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.

Rust can't do this very well because it doesn't build std as part of the project, that's still an unstable option. It's linking object code.

Link-time optimization should have been beneficial for this case... unless you absolutely needed quite a bit of `std` to print backtraces.

C doesn't either, but statically linking still pulls only the object files which are actually needed into the executable.

I think that's the main reason why every stdlib function lives in its own source file in MUSL:

https://git.musl-libc.org/cgit/musl/tree/src/stdio

Not sure if this can easily be replicated in Rust though and LTO must be used instead for dead code removal.

A Rust crate is a single translation unit. It's the precise equivalent of a C source or object file.

A statically linked C hello world is just 5 KBytes though (with MUSL on Linux). Static linking doesn't mean that the entire library is included in the binary, only code that's actually used (details vary depending on how the library was created, and how the program was linked, but those 5 KB are with defaults).

That's ignoring the difference between fixed costs and marginal costs.

When the program grows, the fix costs stop to matter.

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?

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.

They're really gonna panic when they deploy their first qt app then.

Statically linked Qt 4.x wasn't actually so bad. But that's not compatible with the LGPL license for closed-source apps, you had to get a commercial license. The problem with DLL based Qt apps is that you ship a ton of code that's never called.

I was just thinking about the size of the app if you include all the needed libraries for even a basic gui app :) . I guess it was a bit tangential of an comment.

Reply on news.ycombinator.com