| What does it matter if a user never interacts with that API or not? Rust is focused around -safety- and performance. I would rather have a slight performance hit and safe code, rather than trusting some random person to 100% correctly write unsafe code. Which is why tools like cargo-audit and cargo-geiger exist. IIRC Nikolay didn't communicate well about -why- unsafe was used, and just closed PRs that converted unsafe code to safe code. > The unsafe keyword means that I know what I'm doing. Just trust me for once, please. No, it means you think you know what you're doing. It's more likely that you don't know what you're doing and/or are unnecessarily invoking unsafe for convenience, than the opposite. Theoretically I can look at your code and see if it's correct... or I could just use projects that don't use unsafe at all and save the time/headache. When it comes to web server frameworks and security, I would like to see as little unsafe usage as possible, and documentation as to exactly why it's needed. Which is why people switched to Warp/Tower and now Axum which forbids unsafe code entirely. If all I cared about were eking out all performance at the cost of safety, I wouldn't be using Rust in the first place. |
#1: Low level vice applications programming. In the former, unsafe is a regular part of (at least certain layers) of code; ie you're working with memory (MMIO etc) as core operations, so will need `unsafe`. The situation gets ambiguous for things like peripheral typestates and owned singletons for register blocks etc; the line is blurred about what you're using the ownership model for, and what APIs should be marked as `unsafe`. For higher level uses like desktop programs and web servers, you may not need any `unsafe`.
#2: Libraries vice programs This is directly related to your main point: If using someone else's code as a dependency, unsafe can be a liability if you don't know why it's is used. This is one aspect of the broader topic of whether you can/should trust any given dependency, and balancing not re-inventing wheels with learning library quirks, edge-cases, subtle bugs, complexity etc. A spin on this is making infrastructure specifically; I think Actix's creators and users may have had different opinions on this.