4 ms·

> I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (t

by baq 11mo ago

> I don't know what one should even make from that statement. it's just a fact. by definition of the Rust language unsafe Rust is approximately as safe as C (technically Rust is still safer than C in its unsafe blocks, but we can ignore that.) > you didn't even bother to look at the code but still presented of course I did, what I've seen were one-liner trait impls (the 'whole traits' from your own post) and sub-line expressions of unsafe access to bindings.

zozbot234 11mo ago
> technically Rust is still safer than C in its unsafe blocks This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB. Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.
- Xylakant 11mo ago
  It's great that the Google Android team has been tracking data to answer that question for years now and their conclusion is: ------- The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception). The practice of encapsulation enables local reasoning about safety invariants. The additional scrutiny that unsafe{} blocks receive. ----- From https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html?m=1 https://security.googleblog.com/2025/11/rust-in-android-move...
  - zozbot234 11mo ago
    > The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.
    - sophacles 11mo ago
      It actually does support it. Human attention is a finite resource. You can spend a little bit if attention in every line to scrutinize safety or you can spend a lot of time scrutinizing the places where you can't mechanically guarantee safety. It's safer because it spends the human attention resource more wisely.
    - baq 11mo ago
      literally from the quote: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).
      - menaerus 11mo ago
        They also say The practice of encapsulation enables local reasoning about safety invariants. which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obvious. IMHO
        deleted 11mo ago
        [deleted]
        aw1621107 11mo ago
        > which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". Strictly speaking, that encapsulation enables local reasoning about safety invariants does not necessarily imply that encapsulation guarantees local reasoning about safety invariants. It's always possible to write something unadvisable, and no language is capable of preventing that. That being said, I think you might be missing the point to some extent. The idea behind the sentence is not to say that the consequences of a mistake will not be felt elsewhere. The idea is that when reasoning about whether you're upholding invariants and/or investivating something that went wrong, the amount of code you need to look at is bounded such that you can ignore everything outside those bounds; i.e., you can look at some set of code in complete isolation. In the most conservative/general case that boundary would be the module boundary, but it's not uncommon to be able to shrink those boundaries to the function body, or potentially even further. This general concept here isn't really new. Rust just applied it in a relatively new context.
menaerus 11mo ago
So, unsafe block every 70 LoC in 1500 LoC toy example? Sure, it's a strong argument.
- kaoD 11mo ago
  How is that worse than everything being unsafe? I've seen this argument thrown around often here in HN ("$IMPROVEMENT is still not perfect! So let's keep the statu quo.") and it baffles me. C is not perfect and it still replaced ASM in 99% of its use cases.
  - menaerus 11mo ago
    No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust. Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.
    - kaoD 11mo ago
      > Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. You're doing it again! Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement. Also, Rust safety is not related at all to bugs. You seem to have a misunderstanding of what Rust is or what safe Rust provides. (Also, I'd challenge the rest of your assumptions, but that's another story.)
      - menaerus 11mo ago
        What am I exactly doing again? I am providing my reasoning, sorry if that itches you the wrong way. I guess you don't have to agree but let me express my view, ok? My view is not extremist or polarized as you see. I see the benefit of Rust but I say the benefit is not what Internet cargo-cult programming suggests. There's always a price to be paid, and in case of kernel development I think it outweighs the positive sides. If I spend 90% of time debugging freaking difficult to debug issues, and Rust solves the other 10% for me, then I don't see it as a good bargain. I need to learn a completely new language, surround myself with a team which is also not hesitant to learn it, and all that under assumption that it won't make some other aspects of development worse. And for surely it will.

by baq 11mo ago

zozbot234 11mo ago

> technically Rust is still safer than C in its unsafe blocks This is quite dubious in a practical sense, since Rust unsafe blocks must manually uphold the safety invariants that idiomatic Safe Rust relies on at all times, which includes, e.g. references pointing to valid and properly aligned data, as well as requirements on mutable references comparable to what the `restrict` qualifier (which is rarely used) involves in C. In practice, this is hard to do consistently, and may trigger unexpected UB. Some of these safety invariants can be relaxed in simple ways (e.g. &Cell<T> being aliasable where &mut T isn't) but this isn't always idiomatic or free of boilerplate in Safe Rust.

Xylakant 11mo ago
It's great that the Google Android team has been tracking data to answer that question for years now and their conclusion is: ------- The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception). The practice of encapsulation enables local reasoning about safety invariants. The additional scrutiny that unsafe{} blocks receive. ----- From https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html?m=1 https://security.googleblog.com/2025/11/rust-in-android-move...
- zozbot234 11mo ago
  > The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.
  - sophacles 11mo ago
    It actually does support it. Human attention is a finite resource. You can spend a little bit if attention in every line to scrutinize safety or you can spend a lot of time scrutinizing the places where you can't mechanically guarantee safety. It's safer because it spends the human attention resource more wisely.
  - baq 11mo ago
    literally from the quote: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).
    - menaerus 11mo ago
      They also say The practice of encapsulation enables local reasoning about safety invariants. which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obvious. IMHO
      - deleted 11mo ago
        [deleted]
      - aw1621107 11mo ago
        > which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants". Strictly speaking, that encapsulation enables local reasoning about safety invariants does not necessarily imply that encapsulation guarantees local reasoning about safety invariants. It's always possible to write something unadvisable, and no language is capable of preventing that. That being said, I think you might be missing the point to some extent. The idea behind the sentence is not to say that the consequences of a mistake will not be felt elsewhere. The idea is that when reasoning about whether you're upholding invariants and/or investivating something that went wrong, the amount of code you need to look at is bounded such that you can ignore everything outside those bounds; i.e., you can look at some set of code in complete isolation. In the most conservative/general case that boundary would be the module boundary, but it's not uncommon to be able to shrink those boundaries to the function body, or potentially even further. This general concept here isn't really new. Rust just applied it in a relatively new context.

menaerus 11mo ago

So, unsafe block every 70 LoC in 1500 LoC toy example? Sure, it's a strong argument.

kaoD 11mo ago
How is that worse than everything being unsafe? I've seen this argument thrown around often here in HN ("$IMPROVEMENT is still not perfect! So let's keep the statu quo.") and it baffles me. C is not perfect and it still replaced ASM in 99% of its use cases.
- menaerus 11mo ago
  No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust. Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.
  - kaoD 11mo ago
    > Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. You're doing it again! Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement. Also, Rust safety is not related at all to bugs. You seem to have a misunderstanding of what Rust is or what safe Rust provides. (Also, I'd challenge the rest of your assumptions, but that's another story.)
    - menaerus 11mo ago
      What am I exactly doing again? I am providing my reasoning, sorry if that itches you the wrong way. I guess you don't have to agree but let me express my view, ok? My view is not extremist or polarized as you see. I see the benefit of Rust but I say the benefit is not what Internet cargo-cult programming suggests. There's always a price to be paid, and in case of kernel development I think it outweighs the positive sides. If I spend 90% of time debugging freaking difficult to debug issues, and Rust solves the other 10% for me, then I don't see it as a good bargain. I need to learn a completely new language, surround myself with a team which is also not hesitant to learn it, and all that under assumption that it won't make some other aspects of development worse. And for surely it will.