Isn't it a less troden path because it's sacrificing too much and gaining too little, especially when we have languages coming up like rust with the memory safety of a GC but no gc runtime cost?

I ask because I don't have much low-level/embedded experience, and I'm unaware of why you'd want a gc on such low power systems. If there's a use case though, I'd love to learn about it!

I think the question is easier to answer if we view "garbage collection" as automatic memory management in general, rather than a more specific case of automatic memory management via a runtime task colloquially known as the garbage collector. I believe automatic memory management is a universally desirable property whether you are running on a server or a small device. However, since you brought up Rust, I also think it is valid to debate the value of a runtime GC as opposed to another automatic memory management technique like automatic reference counting. I don't think that question is embedded-specific though: it applies just as much to the server environment.

How is tracing GC vs. pervasive reference counting relevant to Rust?

I merely used automatic reference counting as one alternative automatic memory management technique. Rust, as I understand it, uses a similar alternative, which is, at least on paper, similar to enforcing a max refcount of one on pointers, statically. I'm far from a Rust expert so feel free to correct me if I'm wrong.

I'd say that "reference counting" implies a dynamic/runtime component, which is not how Rust manages memory (unless you're specifically using the `Rc` pointer in the stdlib).

I think it's important to be clear here because Swift and Objective-C rely on a technology known as "Automatic Reference Counting" (ARC), which does imply the usual dynamic cost of reference counting.