Rust as a High Level Language

Agreed. Garbage collected languages require 5 times more memory to achieve the same performance as explicit memory deallocation. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%.


And note that immutability can make GC of temporary objects much more efficient:

Haskell's computation model is very different from that of
conventional mutable languages. Data immutability forces us to produce a
lot of temporary data but it also helps to collect this garbage
rapidly. The trick is that immutable data NEVER points to younger
values. Indeed, younger values don't yet exist at the time when an old
value is created, so it cannot be pointed to from scratch. And since
values are never modified, neither can it be pointed to later. This is
the key property of immutable data.

This greatly simplifies garbage collection (GC). At anytime we
can scan the last values created and free those that are not pointed to
from the same set (of course, real roots of live values hierarchy are
live in the stack). It is how things work: by default, GHC uses
generational GC. New data are allocated in 512kb "nursery". Once it's
exhausted, "minor GC" occurs - it scans the nursery and frees unused
values. Or, to be exact, it copies live values to the main memory area.
The fewer values that survive - the less work to do. If you have, for
example, a recursive algorithm that quickly filled the nursery with
generations of its induction variables - only the last generation of the
variables will survive and be copied to main memory, the rest will be
not even touched!

Javascript is an example that immutability isn't the only case of creating too many temporary objects.

I realize Rust can do static analysis of explicit memory deallocation, but tangentially note even reference counting memory management can't be assumed to be real-time:

Not real-time
Naive implementations of reference counting do not in general
provide real-time behavior, because any pointer assignment can
potentially cause a number of objects bounded only by total allocated
memory size to be recursively freed while the thread is unable to
perform other work. It is possible to avoid this issue by delegating the
freeing of objects whose reference count dropped to zero to other
threads, at the cost of extra overhead.

And reference counting memory management isn't faster than GC:

Here are the numbers I got on my dual proc PIII-600:

ref_gc: 531ms
ref_rm: 3563ms
ref_rs: 844ms

And reference counting won't free the dangling circular references that GC will.

Edit: non-crashing "memory leaks" with GC and Rust's resources lifetimes are caused by higher-level semantics and data structures which have unmatched add/remove items{1}. And given that Rust's lifetimes are more unsafe than GC, then Rust may have crash (accessing freed memory) memory leaks which GC doesn't have. Edit#3: the prior sentence is incorrect, as evident by the linked discussion.

Edit#2: on further thought the following paragraph from my prior edit is untrue, except the italicized part remains true:

Although afaik it is possible to model and check these higher-level resource lifetimes with Rust's checker, afaik _Rust can't insure the programmer will or that the code will be reasonably manageable in certain circular dependency imperative spaghetti scenario_s. Another interesting point is that Rust's lifetime checker could be useful even alongside GC.

  1. Can you have memory leaks with a garbage collector? - Stack Overflow