5 ms·

Wouldn't modern C++ be better suited than Rust because it's closer to C? I know that old C++ got some bad reputation in the past but I think it's time to recon

Wouldn't modern C++ be better suited than Rust because it's closer to C? I know that old C++ got some bad reputation in the past but I think it's time to reconsider that with the changes that started with C++11. The only area where Rust really is better is the management of lifetimes and its associated higher memory safety.

_pmf_ 7y ago
> Wouldn't modern C++ be better suited than Rust because it's closer to C? I think the point is that it would be worse because it's closer to C.
the_duke 7y ago
I'll bite. C++ has quite a few powerful features that Rust doesn't have, including better platform support, but Rust has a lot of things going for it that would make it well suited to kernel development: * no exceptions, and language features and a type system that is set up for explicit error handling - the kernel would need to disable C++ exceptions anyway, making error handling just as cumbersome as in C. * the ML inspired type system helps to write correct code (eg sum types) * the language is not riddled with UB and legacy C support induced cruft. You can opt in to unsafety with `unsafe` blocks, but these can be tightly scoped to where it's necessary and can be especially scrutinized Especially in the context of a kernel, the increased safety guarantees are worth a lot.
- majewsky 7y ago
  On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. We're still pretty early in Rust's lifecycle, and there is still a lot to be learned about what `unsafe` can really break, especially at-a-distance. The UCG WG is doing this work in [1], but I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. [1] https://github.com/rust-lang/unsafe-code-guidelines https://github.com/rust-lang/unsafe-code-guidelines
  - nindalf 7y ago
    In my uninformed opinion, it's fairly simple to write Rust code that's easy to review. Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I think it might be at least half a decade before Rust starts being used in more central parts of the kernel (if at all) because adding a second language significantly complicates the build process. Also, it is blocked on Rust supporting all the platforms that Linux supports just as well. It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms.
    - majewsky 7y ago
      > Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I don't have links at hand, but there were already instances where a bug in an `unsafe` block had effects in completely different (and seemingly random) places. Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. > It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms. Which is why driver modules are a good place to start. Drivers are specific to certain pieces of hardware which are oftentimes only used with CPUs of a specific ISA.
      - masklinn 7y ago
        > Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. unsafe blocks can cause UB period, UB means the program is broken but the UB can manifest anywhere. C or C++ don't make this any better, they just make the entire program into a source of UB.
        majewsky 7y ago
        Exactly. But many Rust proponents do not communicate that clearly. They often make it sound like unsafe blocks contain the undefined behavior and prevent it from spreading to the rest of the program, which they don't.
skohan 7y ago
Would kernel development be one of the use-cases where the security benefit of Rust's safety guarantees would outweigh the higher performance ceiling you get with C++? I don't know much about kernel development, so I would be curious what experts think about those tradeoffs.
- lytigas 7y ago
  There's really no evidence that C++ has a higher performance ceiling. From a broad view, both are compiled with no runtime. More specifically, Rust and C/C++ trade the lead constantly in the language benchmarks game. In some cases, Rust can be faster because it makes stack allocating easier. In others, C++ can be faster because of specialization (which Rust doesn't have yet).
  - skohan 7y ago
    Oh really? It's hard to believe that C++ could not achieve better performance with hand-tailored memory management than safe rust. I can understand that unsafe rust should perform about on par with C++.
    - Filligree 7y ago
      Real-world C++ code often copies data far more than is really necessary, because that's the easy way to be sure you aren't mutating a string that someone else expects to remain immutable. Rust's borrow-checker, obviously, prevents that problem. Certainly it's possible to write C++ code which is as efficient -- and in some cases more efficient -- but will it actually happen?
    - rcxdude 7y ago
      Rust's memory safety rarely comes with a significant performance penalty, especially compared with normal C++ practice.
    - roca 7y ago
      Rust has some extra costs, but it also has advantages over C and C++. For example, the Rust compiler can and does reorder fields in structs to improve packing. In C and C++ you have do it manually, and for C++ templated types you sometimes can't pick an order that's optimal for all type parameters. (Rust can pick different field orders for different monomorphized types.) The Rust compiler does other nice representation optimizations, e.g. Option<bool> is represented as a single byte with three possible values. Not just a hack for Options, but general. Maybe even more importantly, Rust is really strict about aliasing and this can improve optimization. E.g. a variable that's a mutable reference to T ("&mut T") cannot alias any other reference to T in scope. An immutable reference to T ("&T") can alias other immutable references to T, but the data is truly immutable (unlike a C or C++ const reference). This completely subsumes "type-based alias analysis" and also C/C++ "restrict", and is stronger than both. This information is potentially really useful for optimizers, but unfortunately, since LLVM is mainly for C/C++, the Rust compiler can't take full advantage of this aliasing information yet :-(.
snaky 7y ago
Actually OS kernels and Linux kernel in particular have many not obvious requirements. Consider easy disassembly for example. > The code generation part ends up being nice when something goes wrong. When somebody sends in an oops, I often end up having to look at the disassembly (and no, a fancy debugger wouldn't help - I'm talking about the disassembly of the "code" portion of the oops itself, and matching it up with the source tree - the oops doesn't come with the whole binary), and then having code generation match the source makes things a _lot_ easier. https://yarchive.net/comp/linux/error_jumps.html https://yarchive.net/comp/linux/error_jumps.html

_pmf_ 7y ago

> Wouldn't modern C++ be better suited than Rust because it's closer to C? I think the point is that it would be worse because it's closer to C.

the_duke 7y ago

I'll bite. C++ has quite a few powerful features that Rust doesn't have, including better platform support, but Rust has a lot of things going for it that would make it well suited to kernel development: * no exceptions, and language features and a type system that is set up for explicit error handling - the kernel would need to disable C++ exceptions anyway, making error handling just as cumbersome as in C. * the ML inspired type system helps to write correct code (eg sum types) * the language is not riddled with UB and legacy C support induced cruft. You can opt in to unsafety with `unsafe` blocks, but these can be tightly scoped to where it's necessary and can be especially scrutinized Especially in the context of a kernel, the increased safety guarantees are worth a lot.

majewsky 7y ago
On the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. We're still pretty early in Rust's lifecycle, and there is still a lot to be learned about what `unsafe` can really break, especially at-a-distance. The UCG WG is doing this work in [1], but I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. [1] https://github.com/rust-lang/unsafe-code-guidelines https://github.com/rust-lang/unsafe-code-guidelines
- nindalf 7y ago
  In my uninformed opinion, it's fairly simple to write Rust code that's easy to review. Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I think it might be at least half a decade before Rust starts being used in more central parts of the kernel (if at all) because adding a second language significantly complicates the build process. Also, it is blocked on Rust supporting all the platforms that Linux supports just as well. It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms.
  - majewsky 7y ago
    > Write unsafe as little as possible and if you need to, put that unsafe block in as small a module as possible. That's mostly it. I don't have links at hand, but there were already instances where a bug in an `unsafe` block had effects in completely different (and seemingly random) places. Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. > It would be disastrous for Linux to drop support for it's long tail of platforms because Linux could no longer be built for those platforms. Which is why driver modules are a good place to start. Drivers are specific to certain pieces of hardware which are oftentimes only used with CPUs of a specific ISA.
    - masklinn 7y ago
      > Discovering all the ways in which `unsafe` blocks can cause unsafe or undefined behavior in unrelated places is still an active field of research. unsafe blocks can cause UB period, UB means the program is broken but the UB can manifest anywhere. C or C++ don't make this any better, they just make the entire program into a source of UB.
      - majewsky 7y ago
        Exactly. But many Rust proponents do not communicate that clearly. They often make it sound like unsafe blocks contain the undefined behavior and prevent it from spreading to the rest of the program, which they don't.

skohan 7y ago

Would kernel development be one of the use-cases where the security benefit of Rust's safety guarantees would outweigh the higher performance ceiling you get with C++? I don't know much about kernel development, so I would be curious what experts think about those tradeoffs.

lytigas 7y ago
There's really no evidence that C++ has a higher performance ceiling. From a broad view, both are compiled with no runtime. More specifically, Rust and C/C++ trade the lead constantly in the language benchmarks game. In some cases, Rust can be faster because it makes stack allocating easier. In others, C++ can be faster because of specialization (which Rust doesn't have yet).
- skohan 7y ago
  Oh really? It's hard to believe that C++ could not achieve better performance with hand-tailored memory management than safe rust. I can understand that unsafe rust should perform about on par with C++.
  - Filligree 7y ago
    Real-world C++ code often copies data far more than is really necessary, because that's the easy way to be sure you aren't mutating a string that someone else expects to remain immutable. Rust's borrow-checker, obviously, prevents that problem. Certainly it's possible to write C++ code which is as efficient -- and in some cases more efficient -- but will it actually happen?
  - rcxdude 7y ago
    Rust's memory safety rarely comes with a significant performance penalty, especially compared with normal C++ practice.
  - roca 7y ago
    Rust has some extra costs, but it also has advantages over C and C++. For example, the Rust compiler can and does reorder fields in structs to improve packing. In C and C++ you have do it manually, and for C++ templated types you sometimes can't pick an order that's optimal for all type parameters. (Rust can pick different field orders for different monomorphized types.) The Rust compiler does other nice representation optimizations, e.g. Option<bool> is represented as a single byte with three possible values. Not just a hack for Options, but general. Maybe even more importantly, Rust is really strict about aliasing and this can improve optimization. E.g. a variable that's a mutable reference to T ("&mut T") cannot alias any other reference to T in scope. An immutable reference to T ("&T") can alias other immutable references to T, but the data is truly immutable (unlike a C or C++ const reference). This completely subsumes "type-based alias analysis" and also C/C++ "restrict", and is stronger than both. This information is potentially really useful for optimizers, but unfortunately, since LLVM is mainly for C/C++, the Rust compiler can't take full advantage of this aliasing information yet :-(.

snaky 7y ago

Actually OS kernels and Linux kernel in particular have many not obvious requirements. Consider easy disassembly for example. > The code generation part ends up being nice when something goes wrong. When somebody sends in an oops, I often end up having to look at the disassembly (and no, a fancy debugger wouldn't help - I'm talking about the disassembly of the "code" portion of the oops itself, and matching it up with the source tree - the oops doesn't come with the whole binary), and then having code generation match the source makes things a _lot_ easier. https://yarchive.net/comp/linux/error_jumps.html https://yarchive.net/comp/linux/error_jumps.html