If you write the Fibonacci generator in one of the first chapters of the Rust book it will create a 4MB binary. Even stripped it's over 400KB.
If you write the same code in Nim it compiles down to 112KB with debug symbols, unstripped. Statically linked against libc (still with debug symbols) it's only 850KB.
850KB statically linked versus ~450KB dynamically linked and stripped.
For code that is virtually identical.
https://internals.rust-lang.org/t/jemalloc-was-just-removed-...
This should reduce binary sizes quite a bit.
Mac OS:
- 1.30.1 before strip: 573K, after strip: 380K
- 1.32.0 before strip: 267K, after strip: 178K
Ubuntu 18.04 LTS:
- 1.30.1 before strip: 3.9M, after strip: 407K
- 1.32.0 before strip: 2.3M, after strip: 191K
when isMainModule:
echo "Hello World"
Before strip: 113k
After strip: 92k
nim c -d:release hello.nim:
Before strip: 79k
After strip: 63k
nim c -d:release --opt:size hello.nim:
Before strip: 46k
After strip: 30k
Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.
I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS...
Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger binary sizes might be difficult.
That said, the smallest executable produced is 145 bytes: https://github.com/tormol/tiny-rust-executable