BatmanAoD

That's fine, just please don't spread misinformation about a language you don't use.

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.

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.

It's actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.

Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ'ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.

Harder than C?

Looks like it wasn't even a bug, just a missed opportunity to use SIMD.

Oh, I thought by "already" you meant right now. I would expect that you can use any Wayland-compatible compositor once their Wayland support is complete, yeah.

Not sure about Steam.

No; Wayland is also a protocol, and Niri relies on that protocol, so Niri doesn't bypass the need for Wayland support.

Do you have a different recommendation for how to display unnameable types in error messages? I'm sure the compiler team would consider any suggestions.

This is hilarious. I'm not sure how often anyone would actually need to verbalize arbitrary binary data, but I do see an advantage over base64 since the English letter names are so often phonetically similar.