You will always need a kind of GC if you start allocating things on the heap. This is because, in some cases, it's impossible for a human or an algorithm to know statically where a memory can be deallocated (you could solve the halting problem if you had a such algorithm, yet the halting problem has been proven unsolvable).
The GC can be very primitive such as in Rust ou C++11 by using reference counting. Reference counting is not a static allocation.
What Rust introduces is memory safety for statically allocated data. That's, the type system will prevent you use a reference/pointer to data a which has been deallocated.
Thank you for bringing this up. Rust does indeed use GCs when it is unable to perform static lifetime analysis, or perhaps more importantly, when the restrictions imposed by the lifetime analysis prove too restrictive for the programmer to solve a given problem.
If you use Rust for any length of time, I think you will find that you almost never need reference counting. You are right that Rust's borrow checker cannot always determine when memory needs to be freed, but the point at which that occurs is much more distant than "when you need to allocate on the heap."
The GC can be very primitive such as in Rust ou C++11 by using reference counting. Reference counting is not a static allocation.
What Rust introduces is memory safety for statically allocated data. That's, the type system will prevent you use a reference/pointer to data a which has been deallocated.