Rust code also has less dynamic memory allocation in general. You allocate for dynamically sized datastructures and long-lived data, but not like c# or java where each non-value class type is allocated on the heap (unless the compiler is smart enough to use escape analysis).
I don't have any long-running Rust code myself, but I do know people who have had Rust servers that have been running for upwards of six months and they seem to be pleased at both how little memory it consumes and at how reliable it's been (you don't ever get tremendous uptime if your code isn't robust in the first place :P ).
I allocate and destroy a bunch of arrays in my code (~100MB every minute), so it's not huge but definitely quite a few pages every time it happens. And so far I've got one process that's been running for 6 months. For the most part, whenever I get new data, I take a slice of an old array and append the new data to it to create a new array. It's fast enough, but more importantly it's just so much easier to do it that way and with a compacting GC I don't have to worry about anything.
Of course I don't know how good jemalloc is at avoiding fragmentation, and I don't have the time to rewrite my code (maybe enough time to simulate, not sure). But my code creates a ton of fragment-y garbage, and I would imagine that with Rust I would end up not just translating my code, but changing semantics to mutate in place, just to avoid fragmentation. I guess maybe /r/rust would be the place to ask.
Not to say it’s impossible in C/C++, but I’ve only ever seen fragmentation issues in old versions of Java and C# where the runtime repeatedly commits large swathes of contiguous memory. The key differentiator here is the VM’s insistence on contiguous allocations, whereas malloc has no such requirements.