Rust can absolutely prevent memory leaks. It depends on how much unsafe rust code you use. Many rust developers find the convenience outweighs the risk of leaks, and take the tradeoff offered by the `Rc` type.
While this is not the direction the standard library took, I think it would be possible to write an alternative stdlib that doesn't choose to allow leaks.
My original statement was probably too strong though. Leak-free code might be possible with rust-the-language, but is probably not possible with rust-the-ecosystem without significant development.
What does the term "unsafe" mean. If a language can have "unsafe code", then it is not safe. I heard the term "unsafe code" used everywhere in relation to c as a excuse for bad code.
So, if you are correct, you can still have leaks in rust, thus removing the number 1 reason to use rust.
Up and down this tread there are people saying "it cannot have leaks" and people saying "yes it can". That tells me moving to rust is not worth the expense and risk because no one knows how safe it is.
Unsafe has a strong name to encourage care about using it but that still doesn’t make it as unsafe as C is by default. You’re telling the compiler that there are certain areas where you have to do something which would normally not be allowed because of some information available to the developer but not the compiler. For example, Rust targets systems programming and it’s likely that you’ll need to do things such as dereferencing a pointer if you have to interact with a C API. Unsafe lets you do that without giving up other protections like the borrow checker and it confines that to specific blocks which you can audit more carefully.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
If I might use a car analogy, going from a mid-20th century language model like C to Rust is like buying a car which has automatic braking and lane assist. Yes, you can still crash if you turn those features off but the ratio of preventable problems to special circumstances where you know you’re doing something tricky is incredibly high.
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.