4 ms·

Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Particularly since Rust allows unsafe operation

by drob518 11mo ago

Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Particularly since Rust allows unsafe operations. That doesn’t mean Rust provides no value over C, just that the value is short of total elimination of bugs. Which was never advertised as the value to begin with.

zamalek 11mo ago
> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.
- samdoesnothing 11mo ago
  > All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel. Which is either 1) not true as evidenced by this bug or 2) a tautology whereby Rust eliminates all bugs that it eliminates.
  - PartiallyTyped 11mo ago
    >> safe Rust > 1) not true as evidenced by this bug Code used unsafe, putting us out of "safe" rust.
  - drob518 11mo ago
    I think the answer is #2, the tautology. But just because it’s a tautology doesn’t mean it’s a worthless thing to say. I think it’s also true, for instance (a corollary), that Rust eliminates more types of bugs than C does. And that may be valuable even if it does not mean that Rust eliminates all bugs.
- lelanthran 11mo ago
  > All bugs is typically a strawman typically only used by detractors. That's obviously not true; we've had years and years of "if it compiles it works" derailing C and C++ forums all over the internet.
tensor 11mo ago
What? I think people think "rust without unsafe" eliminates certain classes of bugs. Are we really going to imply that people don't understand that "unsafe" labeled code is ... uh.. possibly unsafe? I don't believe that these mythical "naive" people exist who think code explicitly labelled unsafe is still safe.
- hnlmorg 11mo ago
  I think the problem lies with the fact that you cannot write kernel code without relying on unsafe blocks of code. So arguably both camps are correct. Those who advocate Rust rewrites, and those who are against it too.
  - ViewTrick1002 11mo ago
    You can’t write rust code without relying on unsafe code. Much of the standard library contains unsafe, which they have in parts taken the time to formally verify. I would presume the ratio of safe to unsafe code leads to less unsafe code being written over time as the full ”kernel standard library” gets built out allowing all other parts to replace their hand rolled implementations with the standard one.
  - jeroenhd 11mo ago
    I don't think this code needed to be unsafe. This code doesn't involve any I/O or kernel pointer/CPU register management; it's just modifying a list. I'm sure the people who wrote this code had their reasons to write the code like this (probably simplicity or performance), but this type of kernel code could be done safely.
    - aw1621107 11mo ago
      As pointed out by yuriks [0], it seems the patch authors are interested in looking into a safer solution [1]: > The previous patches in this series illustrate why the List::remove method is really dangerous. I think the real takeaway here is to replace the linked lists with a different data structure without this unsafe footgun, but for now we fix the bugs and add a warning to the docs. [0]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357 [1]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357
samdoesnothing 11mo ago
> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Classic Motte and Bailey. Rust is often said "if it compiles it runs". When that is obviously not the case, Rust evangelicals claim nobody actually means that and that Rust just eliminates memory bugs. And when that isn't even true, they try to mischaracterize it as "all bugs" when, no, people are expecting it to eliminate all memory bugs because that's what Rust people claim.
- anon-3988 11mo ago
  > Classic Motte and Bailey. Rust is often said "if it compiles it runs". That claims is overly broad, but its a huge, huge part of it. There's no amount of computer science or verification that can prevent a human from writing the wrong software or specification (let plus_a_b = a - b or why did you give me an orange when I wanted an apple). Unsafe Rust is so markedly different than safe default Rust. This is akin to claiming that C is buggy or broken because people write broken inline ASM. If C can't deal with broken inline ASM, then why bother with C?
  - tialaramex 11mo ago
    Yeah. I spent many years getting paid to write C, these days I don't write C (even for myself) but I do write Rust. I write bugs, because I'm human, and Rust's compiler sure does catch a lot more of my bugs than GCC used to when I was writing C all day. Stronger typing a big part of why this happens. For example in C it's perfectly usual to use the "int" type for a file descriptor, a count of items in some container and a timeout (in seconds? milliseconds? who knows). We could do better, but we usually don't. In idiomatic Rust everybody uses three distinct types OwnedFd, usize and Duration. As a result while arithmetic on ints must work in C, the Rust compiler knows that it's reasonable to add two Durations together, it's nonsense to add a Duration to a size, and all arithmetic is inappropriate for OwnedFd, further it's also not reasonable to multiply two Durations together, a Duration multiplied by an integer makes sense and the other way around likewise, but 5 seconds multiplied by 80 milliseconds is nonsense.
- AnIrishDuck 11mo ago
themafia 11mo ago
> That doesn’t mean Rust provides no value over C The real question is "does it provide this greater value for _less_ effort?" The answer seems to be: "No."
- drob518 11mo ago
  No, the real question is whether it provides that greater value for a reasonably acceptable, commensurate effort. Looking for greater value with less effort is looking for a free lunch, and we all know TANSTAAFL.
  - themafia 11mo ago
    > reasonably acceptable Have fun defining that in an open source project. > Looking for greater value with less effort is looking for a free lunch If you have to switch languages to get that value, then no, this has nothing to do with free lunches. > and we all know TANSTAAFL. The church of the acronym. I do not share your apparent faith. Engineering requires you to actually do the work and not rely on simple aphorisms to make decisions.
- timeon 11mo ago
  > The answer seems to be: "No." It is actually "Yes."
Ferret7446 11mo ago
You know one of the best ways to introduce a ton of bugs? Rewriting existing battletested code. Cloudflare is another recent learner of this lesson with their rust rewrite.

by drob518 11mo ago

zamalek 11mo ago

> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.

samdoesnothing 11mo ago
> All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel. Which is either 1) not true as evidenced by this bug or 2) a tautology whereby Rust eliminates all bugs that it eliminates.
- PartiallyTyped 11mo ago
  >> safe Rust > 1) not true as evidenced by this bug Code used unsafe, putting us out of "safe" rust.
- drob518 11mo ago
  I think the answer is #2, the tautology. But just because it’s a tautology doesn’t mean it’s a worthless thing to say. I think it’s also true, for instance (a corollary), that Rust eliminates more types of bugs than C does. And that may be valuable even if it does not mean that Rust eliminates all bugs.
lelanthran 11mo ago
> All bugs is typically a strawman typically only used by detractors. That's obviously not true; we've had years and years of "if it compiles it works" derailing C and C++ forums all over the internet.

tensor 11mo ago

What? I think people think "rust without unsafe" eliminates certain classes of bugs. Are we really going to imply that people don't understand that "unsafe" labeled code is ... uh.. possibly unsafe? I don't believe that these mythical "naive" people exist who think code explicitly labelled unsafe is still safe.

hnlmorg 11mo ago
I think the problem lies with the fact that you cannot write kernel code without relying on unsafe blocks of code. So arguably both camps are correct. Those who advocate Rust rewrites, and those who are against it too.
- ViewTrick1002 11mo ago
  You can’t write rust code without relying on unsafe code. Much of the standard library contains unsafe, which they have in parts taken the time to formally verify. I would presume the ratio of safe to unsafe code leads to less unsafe code being written over time as the full ”kernel standard library” gets built out allowing all other parts to replace their hand rolled implementations with the standard one.
- jeroenhd 11mo ago
  I don't think this code needed to be unsafe. This code doesn't involve any I/O or kernel pointer/CPU register management; it's just modifying a list. I'm sure the people who wrote this code had their reasons to write the code like this (probably simplicity or performance), but this type of kernel code could be done safely.
  - aw1621107 11mo ago
    As pointed out by yuriks [0], it seems the patch authors are interested in looking into a safer solution [1]: > The previous patches in this series illustrate why the List::remove method is really dangerous. I think the real takeaway here is to replace the linked lists with a different data structure without this unsafe footgun, but for now we fix the bugs and add a warning to the docs. [0]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357 [1]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357

samdoesnothing 11mo ago

> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Classic Motte and Bailey. Rust is often said "if it compiles it runs". When that is obviously not the case, Rust evangelicals claim nobody actually means that and that Rust just eliminates memory bugs. And when that isn't even true, they try to mischaracterize it as "all bugs" when, no, people are expecting it to eliminate all memory bugs because that's what Rust people claim.

anon-3988 11mo ago
> Classic Motte and Bailey. Rust is often said "if it compiles it runs". That claims is overly broad, but its a huge, huge part of it. There's no amount of computer science or verification that can prevent a human from writing the wrong software or specification (let plus_a_b = a - b or why did you give me an orange when I wanted an apple). Unsafe Rust is so markedly different than safe default Rust. This is akin to claiming that C is buggy or broken because people write broken inline ASM. If C can't deal with broken inline ASM, then why bother with C?
- tialaramex 11mo ago
  Yeah. I spent many years getting paid to write C, these days I don't write C (even for myself) but I do write Rust. I write bugs, because I'm human, and Rust's compiler sure does catch a lot more of my bugs than GCC used to when I was writing C all day. Stronger typing a big part of why this happens. For example in C it's perfectly usual to use the "int" type for a file descriptor, a count of items in some container and a timeout (in seconds? milliseconds? who knows). We could do better, but we usually don't. In idiomatic Rust everybody uses three distinct types OwnedFd, usize and Duration. As a result while arithmetic on ints must work in C, the Rust compiler knows that it's reasonable to add two Durations together, it's nonsense to add a Duration to a size, and all arithmetic is inappropriate for OwnedFd, further it's also not reasonable to multiply two Durations together, a Duration multiplied by an integer makes sense and the other way around likewise, but 5 seconds multiplied by 80 milliseconds is nonsense.
AnIrishDuck 11mo ago

themafia 11mo ago

> That doesn’t mean Rust provides no value over C The real question is "does it provide this greater value for _less_ effort?" The answer seems to be: "No."

drob518 11mo ago
No, the real question is whether it provides that greater value for a reasonably acceptable, commensurate effort. Looking for greater value with less effort is looking for a free lunch, and we all know TANSTAAFL.
- themafia 11mo ago
  > reasonably acceptable Have fun defining that in an open source project. > Looking for greater value with less effort is looking for a free lunch If you have to switch languages to get that value, then no, this has nothing to do with free lunches. > and we all know TANSTAAFL. The church of the acronym. I do not share your apparent faith. Engineering requires you to actually do the work and not rely on simple aphorisms to make decisions.
timeon 11mo ago
> The answer seems to be: "No." It is actually "Yes."

Ferret7446 11mo ago

You know one of the best ways to introduce a ton of bugs? Rewriting existing battletested code. Cloudflare is another recent learner of this lesson with their rust rewrite.