News for hackers. Stuff that matters.
Re:Rust vs C Pitfalls by cderwin on Wednesday December 28, 2016 @12:42AM (#13268688)
On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat.

Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot.

Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

Re:Rust vs C Pitfalls by Manishearth on Wednesday December 28, 2016 @01:38AM (#13268869)
> But even then, C wins by a lot.

C links dynamically to its libraries. Rust does not (by default).

This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C.

This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.

Re:Rust vs C Pitfalls by cderwin on Thursday December 29, 2016 @12:52AM (#13275867)
Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.
Re:Rust vs C Pitfalls by Manishearth on Thursday December 29, 2016 @01:32AM (#13275999)
Dynamically linking to rust std (with a specially compiled libstd dylib) is an option iirc, just that nobody does it. Lack of stable ABI makes it less useful, but if you really need to do it there's nothing stopping you.

I suspect rust hello world using those libraries is due to a lack of LTO? Hello world doesn't need any of those.

Re:Rust vs C Pitfalls by mmstick on Wednesday December 28, 2016 @01:39AM (#13268871)
Not a particularly fair comparison though, as that C binary is loading dynamic libraries that are already in memory. Case in point: that C program needs the C standard library, but by default that library (glibc) is dynamically loaded. Rust is not offering the Rust standard library as a dynamic library, hence the larger size. Not to mention, interfacing with C functions in the kernel.

You'll get different results if you compile them with musl for truly static and fair binary size comparisons.

Re:Rust vs C Pitfalls by 0xFFC on Wednesday December 28, 2016 @03:13AM (#13269182)
I am no expert, but you should compile barebone executable for comparing executable size! not "hello world", because hello world does use shitload of library (for printing and loading and stuff), and those ones in C is compiled in dynamic, but in rust those compiled inot executable itself.

if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable!

you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.