Memory-security as defined in this article isn't exactly safe. It's just a mitigation feature. The comments above provide plenty of examples of how once an attacker is on the system, he or she can easily get past any language-level construct you care for. If the system were completely memory-safe (which would mean no memory safety bugs in the hardware, kernel, SELinux (or some other kernel extension that lets you do things like deny ptrace), LLVM, the Rust compiler, any libraries you're using, or your program itself, and you weren't doing anything that completely negated all those benefits like JIT compiling code, then you don't need to zero the memory at all--it will do nothing for you as a mitigation technique, and you'd be "memory safe" by your definition. But you're not out of the woods yet, because even with zeroing you are STILL vulnerable to ordinary, non-memory-safety bugs in your code allowing that data to be read. Multiple threads, forgotten heap allocations, and so on. A user with sufficient privileges could glance at the available cache lines. Etc. Anyway, this entire scenario is a fantasy because your system isn't fully memory safe :)

The only way I can think of to actually guarantee real memory security in any meaningful way is to completely verify a much smaller system (not just memory safety, but that it's actually bug-free), isolate it at the hardware level, and do all of your computation using that hardware isolation feature. It has to be hardware because, for example, there's no reasonable way to deterministically erase data swapped to SSD. You'd still be susceptible to hardware bugs, but you can't ever protect against those completely. So basically, get an HSM :)