4 ms·

> It needs a layer of quasi-stable well documented subsystem APIs I think the Rust developers weren't even asking for that. They just want the C developers to

by w10-1 2y ago

> It needs a layer of quasi-stable well documented subsystem APIs I think the Rust developers weren't even asking for that. They just want the C developers to sign up to some semantics. But the C developers know the function interface has evolved to be merely functional: it works, but with few invariants, riddled with caveats and few cross-function guarantees. It can't be hoisted into meaningful semantics, no less a type system, particularly across 10 filesystem API's. Rust developers should focus on drivers in subsystems with stable API's, instead of trying to stabilize what decades of work has failed to.

rowanG077 2y ago
Of course it has semantics. Whether someone knows all of them is a different matter. But whether you use rust or c you have to know the contract to be able to write correct code. The only reason the kernel devs got away with such sloppiness is because c is the ultimate 'I do what you tell me to boss" language.
- deleted 2y ago
  [deleted]
- rc00 2y ago
  And yet, Rust is the exact opposite. Why try to make the two meet? The argument for Rust in the kernel over memory safety can be remediated by better memory safety tools for C can't it? (Not that the Linux kernel project doesn't have any already.) Why not devote the time to writing a better memory safety tool for the Linux kernel (or C in general) rather than keep trying to force two disparate cultures and ideologies to meet in some fantasy middle? ThePrimeagen actually had an interesting opinion on this recently too, worth a watch: https://www.youtube.com/watch?v=62oTu9hjxL4 https://www.youtube.com/watch?v=62oTu9hjxL4
  - steveklabnik 2y ago
    Rust has the very strong pro of already existing. If those tools existed, I’m sure the conversation would be quite different. It’s also not just about memory safety. Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs, for example.
    - rc00 2y ago
      > Rust has the very strong pro of already existing But not in the Linux kernel. Any new effort will be greenfield, why spend the last two years and many more rallying around an entirely different programming language instead of writing a novel tool? > Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs Do you have any examples here?
      - steveklabnik 2y ago
        > But not in the Linux kernel. Sure, it is still an experiment, but that's irrelevant: your theoretical "make C memory safe" tooling does not exist and does not exist in the kernel. > instead of writing a novel tool? Do you have a proposed design for the novel tool? Many have tried, nobody has succeeded. > Do you have any examples here? From the article: > Kroah-Hartman said that it could eliminate entire classes of bugs in the kernel. He's said similar things elsewhere: https://social.kernel.org/notice/AlxbVeMxyJNsLoNa6q https://social.kernel.org/notice/AlxbVeMxyJNsLoNa6q
  - rowanG077 2y ago
    There are no decent memory safety tools for C. Could they be theoretically created? Perhaps, I doubt it considering the amount of money flowing in this industry. To solve it you really have to design a new language. Which is exactly what happened it's called Rust. Kernel devs should just put on their big boy pants and go with the times. C is simply not the right tool for the job anymore for a lot/most kernel work.
  - FuckButtons 2y ago
    Why, because of the cost of exploited vulnerabilities and critical systems failures that could have been avoided.

by w10-1 2y ago

rowanG077 2y ago

Of course it has semantics. Whether someone knows all of them is a different matter. But whether you use rust or c you have to know the contract to be able to write correct code. The only reason the kernel devs got away with such sloppiness is because c is the ultimate 'I do what you tell me to boss" language.

deleted 2y ago
[deleted]
rc00 2y ago
And yet, Rust is the exact opposite. Why try to make the two meet? The argument for Rust in the kernel over memory safety can be remediated by better memory safety tools for C can't it? (Not that the Linux kernel project doesn't have any already.) Why not devote the time to writing a better memory safety tool for the Linux kernel (or C in general) rather than keep trying to force two disparate cultures and ideologies to meet in some fantasy middle? ThePrimeagen actually had an interesting opinion on this recently too, worth a watch: https://www.youtube.com/watch?v=62oTu9hjxL4 https://www.youtube.com/watch?v=62oTu9hjxL4
- steveklabnik 2y ago
  Rust has the very strong pro of already existing. If those tools existed, I’m sure the conversation would be quite different. It’s also not just about memory safety. Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs, for example.
  - rc00 2y ago
    > Rust has the very strong pro of already existing But not in the Linux kernel. Any new effort will be greenfield, why spend the last two years and many more rallying around an entirely different programming language instead of writing a novel tool? > Greg in particular has recognized how Rust’s type system will be helpful for preventing other kinds of bugs Do you have any examples here?
    - steveklabnik 2y ago
      > But not in the Linux kernel. Sure, it is still an experiment, but that's irrelevant: your theoretical "make C memory safe" tooling does not exist and does not exist in the kernel. > instead of writing a novel tool? Do you have a proposed design for the novel tool? Many have tried, nobody has succeeded. > Do you have any examples here? From the article: > Kroah-Hartman said that it could eliminate entire classes of bugs in the kernel. He's said similar things elsewhere: https://social.kernel.org/notice/AlxbVeMxyJNsLoNa6q https://social.kernel.org/notice/AlxbVeMxyJNsLoNa6q
- rowanG077 2y ago
  There are no decent memory safety tools for C. Could they be theoretically created? Perhaps, I doubt it considering the amount of money flowing in this industry. To solve it you really have to design a new language. Which is exactly what happened it's called Rust. Kernel devs should just put on their big boy pants and go with the times. C is simply not the right tool for the job anymore for a lot/most kernel work.
- FuckButtons 2y ago
  Why, because of the cost of exploited vulnerabilities and critical systems failures that could have been avoided.