4 ms·

I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to sys

by fefe23 7y ago

I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). For comparison: ripgrep (Rust) is >2 MB stripped, GNU grep is <200k stripped. I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I'm sure the Rust people will at some point find a way to reduce the footprint of the runtime. Currently they have other, more pressing goals. Personally, I wrote my own init system. The PID 1 process is a 10k statically linked binary. Resident memory size is 24k on one of my AMD64 Linux production servers. That is what I think could rightfully be called a minimal subset.

mmcallister 7y ago
So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I understood it as as a subset of features. It doesn't seem to me that the author is trying to play code golf with their codebase, or optimize for binary size (and why would you in 2019, storage is cheap)
reificator 7y ago
> I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). > I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. Isn't this simply a result of the C runtime not being bundled with the executable? How does the comparison look when accounting for that difference?
- Gibbon1 7y ago
  C does type erasure, doesn't do runtime checking and maps most everything to assembly. I haven't checked recently but last time I did Rust's bare metal binaries were larger than C ones. Might be better now. That said you can beat C's code size with hand assembly and p-code interpreters.
- nwmcsween 7y ago
  Depends obviously but in general small, busybox is statically linked that uses a relatively large swath of libc and you can compare different libc versions somewhat by looking at the tags here: https://hub.docker.com/_/busybox?tab=tags https://hub.docker.com/_/busybox?tab=tags. If parent was correct you could link all of musl libc and have 1.3MB or so left over for an actual application. It also depends on the how the code is structured, musl for example is structured not to pull in unneeded objects while the size of the glibc docker container speaks for itself.

by fefe23 7y ago

mmcallister 7y ago

So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me. I understood it as as a subset of features. It doesn't seem to me that the author is trying to play code golf with their codebase, or optimize for binary size (and why would you in 2019, storage is cheap)

reificator 7y ago

> I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd). > I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original. Isn't this simply a result of the C runtime not being bundled with the executable? How does the comparison look when accounting for that difference?

Gibbon1 7y ago
C does type erasure, doesn't do runtime checking and maps most everything to assembly. I haven't checked recently but last time I did Rust's bare metal binaries were larger than C ones. Might be better now. That said you can beat C's code size with hand assembly and p-code interpreters.
nwmcsween 7y ago
Depends obviously but in general small, busybox is statically linked that uses a relatively large swath of libc and you can compare different libc versions somewhat by looking at the tags here: https://hub.docker.com/_/busybox?tab=tags https://hub.docker.com/_/busybox?tab=tags. If parent was correct you could link all of musl libc and have 1.3MB or so left over for an actual application. It also depends on the how the code is structured, musl for example is structured not to pull in unneeded objects while the size of the glibc docker container speaks for itself.