I've been trying to read it for a couple minutes now and I feel like I'm too dumb to realize what it's saying.

Yeah. I know. And I could tell, but it drives me batty. But also: thorn is an English character!!

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.

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.

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"

Wasn't Rust originally made for embedded systems to reduce the time taken debugging runtime errors by shifting those to compile time?