There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features
Such as? busybox provides a nice interactive shell, awk, bc, wget and much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.
busybox also implements [[ from bash, none of this is provided by uutils or coreutils.
EDIT: busybox also provides grep while the uutils/coreutils don’t.
I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
I’m assuming this uses -Os which means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.
The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts…
BusyBox has been written with size-optimization and limited resources in mind.
Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.
The utilities in BusyBox generally have fewer options than their full-featured GNU cousins
Note: GNU cousins, not GNU coreutils.
GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.
If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.
If you have gigabytes of storage and memory Rust makes more sense. C shines as it allows fine control over memory. The fact that you can tie into The system libraries makes it very resource friendly since you don’t need redundant code.
You can tailor the rust standard library to be more embedded friendly in several way, like if you don’t have dynamic memory allocation or a filesystem, you can get the standard library sans those features.
Rust also gives you a very fine grained level of control of memory, I think equivalent to C (maybe there’s some gotcha that I’m not aware of but if not equivalent very close).
It really doesn’t sound like you know that much about Rust here and are just making things up, you certainly don’t need “gigabytes of storage and memory”
I think you’re making some poorly-researched assumptions.
In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print
Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.
But will a good hello world program, made in JS, run on Firefox on an Embedded Windows 11 OS, running on a CPU emulator running on WASM on Edge be more performant than a mediocre hello world program in C, running on Linux on the same hardware that Edge run on?
It depends on what you are counting as “performance”
Good C code is way better than mediocre Rust code. C also has much smaller binaries.
“good code is better than mediocre code” definitely one of the statements of all time.
If your goal is small binaries, it’s possible to get them with Rust, too: https://github.com/johnthagen/min-sized-rust
There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.
rust still produces larger binaries even if you compare it to static C binaries.
Take for example busybox, you can compile all of it as a single 1.2 MiB static binary that provides 395 utilities including wget.
Meanwhile the uutils static musl binary is 12 MiB and only provides 115 utilities.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
Such as? busybox provides a nice interactive shell,
awk,bc,wgetand much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.busybox also implements
[[from bash, none of this is provided by uutils or coreutils.EDIT: busybox also provides grep while the uutils/coreutils don’t.
I’m assuming this uses
-Oswhich means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.From the busybox “about” page:
Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.
Note: GNU cousins, not GNU coreutils.
GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.
If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.
Busybox
lshas 26 flags. GNUlshas 60.fair, in that case the comparison is even since busybox provides a shell, awk, grep, wget among other 395 utils, uutils it is 115.
C is still better for the embedded world
If you have gigabytes of storage and memory Rust makes more sense. C shines as it allows fine control over memory. The fact that you can tie into The system libraries makes it very resource friendly since you don’t need redundant code.
You can tailor the rust standard library to be more embedded friendly in several way, like if you don’t have dynamic memory allocation or a filesystem, you can get the standard library sans those features.
Rust also gives you a very fine grained level of control of memory, I think equivalent to C (maybe there’s some gotcha that I’m not aware of but if not equivalent very close).
It really doesn’t sound like you know that much about Rust here and are just making things up, you certainly don’t need “gigabytes of storage and memory”
I think you’re making some poorly-researched assumptions.
In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print
Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.
I find it way easier just to use C
It is simple and clean
That’s fine, just please don’t spread misinformation about a language you don’t use.
Wasn’t Rust originally made for embedded systems to reduce the time taken debugging runtime errors by shifting those to compile time?
“Thing I say is good, is better than thing I say is mediocre.”
Indeed.
But will a good hello world program, made in JS, run on Firefox on an Embedded Windows 11 OS, running on a CPU emulator running on WASM on Edge be more performant than a mediocre hello world program in C, running on Linux on the same hardware that Edge run on?