Well it depends on how you define memory leaks. Memory leaks can of course occur logically. Like say you create objects in a cache and never remove them. It is still a memory leak.
But at the level that you define the memory leak, it seems Rust can be just as good as Go because memory ownership is tracked by the compiler. One can say it is even better because of compile time checks and no need to have a GC @ runtime present.
However, in practice most values can be neither Rc nor Gc but single-owner, like unique_ptr in C++, which is easier to reason about than either.
So far so good. But You forget to allocate smaller array (and copy members) when you consume too much memory. So 1000000* push(something) followed by 1000000*pop() keeps plenty allocated memory not in usage.
(It's not as brutal as malloc() and forget the result but still pretty awfull situation in a large project.)
To catch _some of_ them :) No guarantee that they will all be caught.
> The cost of race detection varies by program, but for a
> typical program, memory usage may increase by 5-10x and
> execution time by 2-20x.
- Both Go and Rust use bounds checking on arrays/slices (which means out-of-bounds accesses are not allowed).
- Go is garbage collected, so memory leaks cannot occur.
- Rust encourages an ownership/lifetime model, so memory leaks cannot occur.
- Go can still have data races between multiple concurrent threads. To catch them, you must use the race detector _at run time_. Note however that Go encourages communicating information over channels, and if idiomatic code is being written the chance of data races is next to none.
- Rust cannot have data races in most cases, as it's ownership/lifetime model allows for catching them _at compile-time_.
- Both of these assumptions are based on no external C or unsafe code being in the picture.
TL;DR: Very similar.
EDIT: I used the wrong terminology -- sorry. Instead of _memory leak_ I should have said _dangling pointers_ (memory leaks can occur in _any_ language, Go/Rust/Java/JS/etc).