4 ms·
This is great and I love Rust, but > However, when working directly with the hardware, which has no knowledge of Rust’s guarantees, it is necessary to work in
by privethedge 7y ago
This is great and I love Rust, but
> However, when working directly with the hardware, which has no knowledge of Rust’s guarantees, it is necessary to work in Rust’s unsafe mode, which allows some additional behaviors, but requires the developer to uphold certain correctness guarantees manually.
If the whole code will be wrapped in unsafe blocks, then what is the point of using Rust?
- hackcasual 7y agoThis example is a bit of an outlier since it's so small, but a larger program is going to need proportionally smaller amounts of unsafe code. Remember, just because it's marked unsafe, doesn't mean it's not rust. It's just that for doing low level micro-controller type things, you're explicitly addressing parts of RAM (or memory mapped I/O), and that means creating your own pointer.
- chubs 7y agoSo is it the case that you only need 'unsafe' for some of your codebase where you're eg bit-banging, or using peripherals, or whatever - but the majority of your logic is running in normal 'safe' mode?
- littlestymaar 7y agoThat's right. For instance, in the redox-os kernel, there is less than 100 places where unsafe is needed : https://doc.redox-os.org/book/introduction/unsafes.html https://doc.redox-os.org/book/introduction/unsafes.html.
- mlindner 7y agoAnd to be more specific you'd ideally write an interface implementation that does that bit banging for you such that you call those functions from your safe code.
- PudgePacket 7y agoSome amount of unsafe is impossible to avoid for doing certain things. Rust unsafe allows developers to focus their memory auditing efforts, rather than existing languages where _everywhere_ must be checked. Here's an example. The Rust standard library has unsafe code to do things like allocate memory and read from files. However, it provides a safe abstraction that my code can use "safely" and be confident I won't encounter any memory errors. Or if you're writing some kind of concurrent data structure, you want to be doing pointer and memory shenanigans for efficiency, but you'd make a safe API for consumers of the data structure. I think a lot of people are scared initially seeing something like "unsafe". It's kind of equivalent to just regular C/C++ land... It doesn't automatically mean "The program will now eat your memory".
- PudgePacket 7y agoEcosystem, build tools, ergonomics, familiarity, etc. Rust is more than just handrails for C code.
- cttet 7y agoWhy not? There are people who are more familiar with Rust than C/C++, why shouldn't they use a more familiar language?
- baq 7y agoat that point you're getting the worst of both worlds: no safety guarantees and a very complex language.
- paavohtl 7y agoUnsafe Rust has significantly more safety guarantees than C or C++. It doesn't disable the type system, bounds checking, ownership tracking or borrow checking.
- CaptainMarvel 7y agoWhat does Unsafe Rust disable then?
- steveklabnik 7y agoIt does not disable, it enables. Unsafe doesn't turn anything off, it adds new capabilities instead. https://doc.rust-lang.org/nomicon/what-unsafe-does.html https://doc.rust-lang.org/nomicon/what-unsafe-does.html
- IshKebab 7y agoYou don't have to do everything in unsafe blocks.