[flagged]
The danger of Rust it that you twist yourself into a bretzel in order to avoid unsafe, while you should have in fact made a exceptionally well tested and designed unsafe block that is surrounded by code that the compiler checks for you.
I am still convinced that the naming choice for unsafe has some effects that were not intended. Mentally whenever you see unsafe fill in a "trust me" or a "manual override" or whatever. Something that tells you that the programmer had a reason to override the borrow-checker. If they are cool they tell you why the thing they did is indeed safe and sound code.
As an example, both the popular generic self-referencing crates ouroboros and self_cell have had memory safety bugs in them in the past. (links at the end) Both of them were carefully reviewed by experienced rust developers before their first public release, and yet they still ended up with such bugs. Admittedly, part of the issue is that both crates are trying to be more generic, so they have to be correct over a larger range of circumstances.
But still, these crates have one job, are both less than 1500 LOC, and they were carefully reviewed to ensure they did that one job before their public releases, and they still ended up having issues that were not caught. They might still have issues.
Thus, while it might be fine to use unsafe to state that your array of zeros is a valid utf-8 string without a runtime check, it's probably a good idea to twist yourself into a pretzel if the invariants are not trivial to prove and the overhead to maintenance/runtime isn't too high.
[0]: https://rustsec.org/advisories/RUSTSEC-2023-0042.html [1]: https://rustsec.org/advisories/RUSTSEC-2023-0070.html
trusted { … }`unsafe` is the part where the compiler trusts you to uphold your own invariants, necessary to prevent Unsoundness. For example:
- unsafe fn get_unchecked(index) - compiler believes you will ensure index < length.
- unsafe fn set_capacity(capacity) - compiler trusts you will not set capacity to value that will cause UB. Even if its code boils essentially to set a field - which is safe according to Rust, but may invalidate other invariants preserving soundness.
trustMeBro { ... } dangerzone { ... }LVM: Hey there was this Linux summit on file systems and Rust was discussed
HN commenter: has Rust evangelism gone too far!?
I swear HN commenters are more over the top than tabloid headlines sometimes.
I'm glad this conversation is happening, though.
Not in this case. It's the Rust evangelist who is the newcomer. FTA:
> Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they can be encoded into Rust.
The responses from the kernel team members to the proposal seem reasoned and mature to me:
> In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work?
> As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync.
> The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs.
> Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems.
> Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted.
> Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint
> But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".
From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.
Kent Overstreet is the bcachefs maintainer and he's extremely pro-Rust. He has in fact talked about wanting to move bcachefs to Rust, and the userspace tools for bcachefs are already written in Rust.
He's been participating in the mailing list discussions about using Rust / providing Rust APIs for the FS subsystem.
I don't know who you're confusing him with, but you're confusing him with someone else.
Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered?
From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.
He's already written - with a considerable amount of collaboration of course - the world's most popular kernel and the world's most popular source control system. I expect he'd be able to do the same for a new and improved systems language if he put his mind to it.
Pick one.
The safety is achieved by eliminating constructs which cannot be proven to be safe. Additionally, Rust-style safety involves adding more information explicitly to the source which otherwise has to be kept in the programmer's head (or externally like sel4): object lifetimes, lock rules (see original article), etc.
At best you end up with "first wrap all your original code in 'unsafe' and then gradually move the safety boundary", but even that is very difficult.