5 ms·

> It basically won’t compile if your code would have runtime errors or memory leaks While Rust does move a lot of errors from runtime to compile time, there ar

> It basically won’t compile if your code would have runtime errors or memory leaks While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all). Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap allocation. [1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...

xyzzy4747 4y ago
The difference is you need to explicitly handle cases that would cause runtime errors where you have to use .unwrap() or match selectors, which makes it safer in general. Since the values are wrapped in Result or Option enums. Code that doesn’t create these types isn’t possible to have runtime errors which reduces cognitive burden when coding. And yes you can write non-idiomatic Rust that lets you leak memory but it doesn’t happen by accident like in C/C++.
- zozbot234 4y ago
  > Code that doesn’t create these types isn’t possible to have runtime errors Rust code can still panic and unwind at runtime. There's some ongoing work on supporting guaranteed-not-to-panic code for very specific uses (similar for guaranteed-not-to-leak, which is a related problem), but it's a long way off and will not be applicable to anything that must interact with the system in any way.