This is a hyperbolic comment. You are either simplifying to the core, are misinformed or ignorant. There is a nuance. You can have leaks in every language incl

This is a hyperbolic comment. You are either simplifying to the core, are misinformed or ignorant. There is a nuance. You can have leaks in every language including garbage collected ones. Allocate a shared OS resource like a semaphore and don't give it back, there you go you have a leak that survives until the next reboot. Safety as Rust means requires below: - The program cannot call an operation that accesses invalid memory i.e. uninitialized memory and invalid memory areas. - The program cannot substitute a memory location that defined as a particular type as another type. - The program cannot make calls to an operation that causes the runtime environment (OS, CPU interrupts, running modes, system registers etc) that causes the two issues above. If you have already allocated memory that just stays as it is, this is safe. The action of allocating it can be unsafe if the program makes a call to libc allocator since libc calls are outside of the Rust compilers' control. Similarly directly calling the page allocator of the OS will also be unsafe since Rust compiler doesn't have complete control of the OS and internal structure of the CPU. Similarly freeing memory may also change the page tables. Moreover Rust makes it easier to create data structures that clean after themselves. This is not a direct safety issue. It is a language feature. The standard library makes extensive use of these. So the common programming patterns usually mitigate the risks of leaking resources but not eliminate.