That part is amazing. I personally do not have a real use case to exploit it [1], just find it neat from an engineering viewpoint...
I guess, it has an aggressive dead code removal process, compared to other - nowadays hot - compiled languages (Go, Haskell, Rust, D, Crystal). In those languages if you use a small part of their standard library, you usually get large chunks of it linked in statically (+ runtime if there is such)...
(Once I've tried LTO with one of my Rust project: it increased the build time tremendously but in the end it managed to shave off only 30KB from my several MB binary...)
[1] If I would try micro controller programming ever, I probably would give Nim a shot because of this...
I've just tried now some Rosetta code examples. Most of it had to be modified a bit to get compiled with this Nim version although. (adding types, change case of type names)
Used -d:release --opt:size, then strip, Ubuntu 16.04 64 bit. The binary sizes:
The binaries are dynamically linked only to the common standard C prog. dependencies on Linux: linux-vdso.so.1, libc.so.6, ld-linux-x86-64.so.2
(Except for the gtk2 example of course, which uses libdl to to pull in a large bunch of additional gtk dependencies too...)
That part is amazing. I personally do not have a real use case to exploit it [1], just find it neat from an engineering viewpoint...
I guess, it has an aggressive dead code removal process, compared to other - nowadays hot - compiled languages (Go, Haskell, Rust, D, Crystal). In those languages if you use a small part of their standard library, you usually get large chunks of it linked in statically (+ runtime if there is such)...
(Once I've tried LTO with one of my Rust project: it increased the build time tremendously but in the end it managed to shave off only 30KB from my several MB binary...)
[1] If I would try micro controller programming ever, I probably would give Nim a shot because of this...