4 ms·

(Not a regular rust developer, so take this with a large grain of salt) Rust can absolutely prevent memory leaks. It depends on how much unsafe rust code you u

by cobbal 2y ago

(Not a regular rust developer, so take this with a large grain of salt) 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.

mpolun 2y ago
[dead]
jmclnx 2y ago
>It depends on how much unsafe rust code you use. 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.
- acdha 2y ago
  Leaks aren’t a memory safety issue, so that’s not one of the reasons for using Rust although the modern language design does make it less prone to accidental leaks. 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 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.
- okanat 2y ago
  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.
SAI_Peregrinus 2y ago
Box::leak() and std::mem::forget() are safe code. Memory leaks are unrelated to memory safety.
- cobbal 2y ago
  "Safe" is unfortunately overloaded here. I wasn't trying to say anything about memory safety. `leak` and `forget` may be memory-safe, but they can only be implemented with `unsafe` code to circumvent the liveness/"relevant" guarantees of the type system. 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.

by cobbal 2y ago

mpolun 2y ago

[dead]

jmclnx 2y ago

>It depends on how much unsafe rust code you use. 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.

acdha 2y ago
Leaks aren’t a memory safety issue, so that’s not one of the reasons for using Rust although the modern language design does make it less prone to accidental leaks. 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 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.
okanat 2y ago
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.

SAI_Peregrinus 2y ago

Box::leak() and std::mem::forget() are safe code. Memory leaks are unrelated to memory safety.

cobbal 2y ago
"Safe" is unfortunately overloaded here. I wasn't trying to say anything about memory safety. `leak` and `forget` may be memory-safe, but they can only be implemented with `unsafe` code to circumvent the liveness/"relevant" guarantees of the type system. 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.