Kang Seonghoon

In general, https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h… For this specifically, I made some numbers when it first landed: https://www.reddit.com/r/rust/comments/575pp6/compiling_to_the_web_wit… Regardless, this is in a "oh my god it works" state, not a super serious best-we-can-do state. My understanding is that it's larger than it has to be at the moment. We'll get there.

Crinkler [1] is a popular compressor-linker for 1--8 KB demos and its decompressor (partially overlapping with a PE header) is probably around 1--200 bytes. Later efforts like oneKpaq [2] also have a comparable decompressor size. If you don't mind a shameless plug and a slightly larger decompressor (about 500 bytes in JS) for better compression, my Roadroller [3] might fit the bill as well. [1] https://github.com/runestubbe/Crinkler [2] https://github.com/temisu/oneKpaq [3] https://lifthrasiir.github.io/roadroller/

There's a lot that can be done to shrink a Rust binary[0]. A copy of the summary: - Compile with --release. - Before distribution, enable LTO and strip the binary. - If your program is not memory-intensive, use the system allocator (assuming nightly). - You may be able to use the optimization level s/z in the future as well. - I didn’t mention this because it doesn’t improve such a small program, but you can also try UPX and other executable compressors if you are working with a much larger application. [0]https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

It's a matter of platform and the libraries that you're using. After all, back in the days we had 360k floppy disks, and executable written in C which did much more than just printing out "Hello world" would fit comfortably into less than half of that. Modern C and C++ runtimes are bloated, because a 2MB executable isn't considered huge anymore and dynamic linking is common. But you can have a 5k static executable printing "hello world" on Linux if you just trade in your stdlibc to musl. People have also managed to use musl with Rust to produce pretty small executables: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

Actually, the culprit is Rust's decision to statically link its standard library and all its dependencies by default. Things like libunwind, libbacktrace, embedded debugging symbols for backtraces, and the jemalloc allocator aren't free. If you ask for dynamic linkage (with the caveat that Rust doesn't have a stable ABI yet), you get a ~8K Hello World binary. It's also possible to prune down the statically-linked size by opting out of various conveniences like jemalloc. (They're working toward making the system allocator default but don't want to regress Servo in the interim.) ...and if opt into static linking with GCC and G++ (and ask Rust to make its link to libc static), Rust can actually outdo them on a Hello World. Here's a detailed exploration: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

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-executable-large.h…

The bloat issues are (a) a constant overhead and (b) a matter of defaults. See https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h… Rust statically links to libstd by default because it's not there as a dynamic lib on most platforms. On top of that, it links in jemalloc. This makes small Rust binaries look larger than they need to be. The overhead dwindles as you start looking at larger Rust programs. If you actually need to get rid of that overhead, the option is there, it's just not default. Addition to popular package managers is being worked on.

> Until Rust can solve its massive binaries, that is somewhere on their roadmap, it just isn't appropriate for use in the embedded world, where kilobytes still count. A demo written in Rust [1] won a 64kB demo competition against C and C++ competitors. It is already solved if the binary size is a problem for you. You can easily get down to 160kB without a whole lot of effort (i.e. avoiding libstd) [2]. [1]: https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysian_1st_pla… [2]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

Have you seen that rustup makes using musl with rustc really easy [0]? One can then additionally forgo things like the optimised jemalloc allocator and the main standard library (just using libcore) to knock the binary size down to what C gives. [0] discusses this in much more detail (especially towards the end). [0]: https://blog.rust-lang.org/2016/05/13/rustup.html#example-building-sta… [1]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

> A static library is a whopping 2.4 MB. The comparable number for C are 4K and 800 bytes respectively. It is possible to significantly optimize that number [0]. Not that binary size is not an issue, but rather 2.4mb vs. 4kb is not an apples to apples comparison [0]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h…

> Chrono is pretty good. For purposes of comparison to other libraries, here's a link to Chrono's documentation: https://lifthrasiir.github.io/rust-chrono/chrono/

> Rust makes enormous binaries Rust binaries are optimized to be fast (by default, fast != small), this [0] explains pretty well why, and min-sized also has many optimizations [1]. > and compiles slow You can have a very slow compiler with all the optimizations and safety checks, or a fast one which doesn't. This however doesn't mean there is no room for improvement. One thing that can definitely improved on is how cargo manages dependencies, I am tired of each of my project's /target directory using >2GB of disk space, there at least should be some kind of opt-in global cache. I am also worried about dependencies going in the same direction as the JS ecosystem, many of my projects only have 3-5 top level dependencies, but I end up downloading hundreds. A few are only compile-time, but this makes auditing very difficult and does make compile times a lot longer. [0]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.h… [1]: https://github.com/johnthagen/min-sized-rust

> If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason. Notice how all those package managers are for platforms or create platforms in their own right. Rust is meant to be a systems language, that means it's platform is the OS and it doesn't get to be a world unto itself like java. > This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... has the details. So if you jump through a million hoops, limit yourself to c libraries you can produce small executables. At that point it's more complicated than just writing an app in c in the first place. I'm not interested in what it can technically do though, I'm interested in what is practically happening. In practice most rust programmers seem to be writing apps for the cargo platform. In practice rust developers are producing huge executables. In practice rust has no stable ABI so all rust libraries get statically compiled. In practice this is incompatible with the LGPL. In practice a security vulnerability means every app using the library has to be recompiled to be secure.