4 ms·

>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 te

by 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.

by jmclnx 2y ago

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.