If you don't allocate, why do you even need Go or Rust? LLMs handle less elegant syntax just as well. I use a zero-malloc C dialect with slices and bounds-checking.
Just recently I was sketching a smallish database in zero-malloc C. https://replicated.live/blog/db That was partly because most LSM data structures are read-only, so mmap was good enough and concurrent access was safe for the bulk of the data.
The "hot zone" (memtable) then requires some intricate engineering, but that is the case either way.
You can go quite far with zero-malloc C.
It can be useful to have zero-alloc libraries in Go, for use in larger programs that do allocate. See https://github.com/rs/zerolog for example.
Rust doesn't have heap allocation in the language at all. It still has useful features regardless.
Technically, malloc() is a library function, not core C. My point is this: guarantees cost complexity, and you always have to keep in mind the assumptions and how much of it is theater. So, neither way is strictly better. It depends. For immutable data, lifetimes don't buy much, for example.
Yeah, I'm not saying C does, just that Rust's features aren't limited to "helping you with heap memory." Rust is also more than lifetimes.