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
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"
nim c hello.nim: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