3 ms·

> raw pointer arithmetic and problematic memcpy() calls can be eliminated, array accesses can be checked at run time, and error paths can be greatly simplified.

> raw pointer arithmetic and problematic memcpy() calls can be eliminated, array accesses can be checked at run time, and error paths can be greatly simplified. Complicated algorithms can be expressed more succinctly through the use of more modern abstractions such as iterators, ranges, generics, and the like. I know why people choose Rust today, but we could have had all of those benefits decades ago if not for the recalcitrance of reflexive C++ haters.

pas 3y ago
Of course, but ergonomics, vibe, or look-and-feel are important. C++ doesn't have a package manager, the .hpp thing is a mess (modules took ages), SFINAE, preprocessor macros vs proc-macros, and so on. That said, Linux is a very conservative and idiosyncratic project. It's really the bazaar. (No issue tracker, firehose of emails, etc.)
- vlovich123 3y ago
  is the kernel using cargo? I don’t think the package manager is relevant.
  - steveklabnik 3y ago
    It is not using Cargo.
  - pengaru 3y ago
    absolutely not
- jsheard 3y ago
  > (modules took ages) They're arguably still not there yet, sure the standard was ratified years ago but the implementations are still a mess and uptake is almost nonexistent.
- flohofwoe 3y ago
  Not to mention: what C++ subset to use, and how to deal with the endless discussion-circlejerks around that one topic alone. For instance most of the C++ stdlib is useless for kernel (or embedded) development, so you end up with a C++ that's not much more than a "C with namespaces". At least Rust brings a couple of actual language improvements to the table (not a big fan of Rust, but if the only other option is C++, then Rust is the clear winner).
  - jeffbee 3y ago
    None of the C stdlib can be used in the kernel, either, and yet the kernel is written in C. Zircon is an existence proof that you can use the C++ std library in a kernel. Do they use every damned thing in std? No, but they do use array, pair, unique_ptr, iterators, and more.
    - SAI_Peregrinus 3y ago
      > None of the C stdlib can be used in the kernel, either, Except the bits allowed in a freestanding environment and (stretching the definition of "used in") the "nolibc" partial C standard library the kernel includes for environments that don't have any other libc available (`tools/include/nolibc`, mostly used for kernel tests where there's no userspace at all).
dale_glass 3y ago
C++ even today has plenty footguns that will make code unsafe, and some of the safety comes at performance costs, or uses features that are ill-suited for the kernel.
b20000 3y ago
there is nothing problematic about memcpy, the problem is that you need to know what you are doing and rust won’t solve that problem.
- deleted 3y ago
  [deleted]
jeroenhd 3y ago
It took C++ decades to get good, in my opinion. If the kernel team had switched to C++ decades ago, we probably would've ended up with a worse kernel code base. For me, C++11 and C++14 created the modern C++ that's actually usable, but compilers took a while to implement all those features (efficiently and correctly). I find the C++ equivalent of the Rust iterators and such to be even harder to read (almost an accomplishment, given the density of Rust code); I don't think features like ranges would be expressed more succinctly using std::range the same way it can be done in Rust, for instance. I also find C++'s iterators' API design rather verbose, and I don't think there's much good to be said of implementing generics through C++ templates. There are good reasons for why the language was designed this way, but I get the impression succinctness didn't seem to be a primary objective designing them. Rather, I get the feeling that the language designers prioritised making the features accessible to people who already knew C++ and were used to the complexer side of C++.
akira2501 3y ago
> the recalcitrance of reflexive C++ haters. I don't reflexively hate C++, just all the implementations of it.
tialaramex 3y ago
Crucially, the Rust for Linux people proposed to do the work to make Rust for Linux. Whenever we see this complaint from C++ people their idea is basically "LOL, Linus should rewrite kernel to be suitable for C++" and the answer is No. That's not going to happen. Once you refuse their fantasy "Don't lift a finger" way to add C++, they lose interest.

pas 3y ago

Of course, but ergonomics, vibe, or look-and-feel are important. C++ doesn't have a package manager, the .hpp thing is a mess (modules took ages), SFINAE, preprocessor macros vs proc-macros, and so on. That said, Linux is a very conservative and idiosyncratic project. It's really the bazaar. (No issue tracker, firehose of emails, etc.)

vlovich123 3y ago
is the kernel using cargo? I don’t think the package manager is relevant.
- steveklabnik 3y ago
  It is not using Cargo.
- pengaru 3y ago
  absolutely not
jsheard 3y ago
> (modules took ages) They're arguably still not there yet, sure the standard was ratified years ago but the implementations are still a mess and uptake is almost nonexistent.
flohofwoe 3y ago
Not to mention: what C++ subset to use, and how to deal with the endless discussion-circlejerks around that one topic alone. For instance most of the C++ stdlib is useless for kernel (or embedded) development, so you end up with a C++ that's not much more than a "C with namespaces". At least Rust brings a couple of actual language improvements to the table (not a big fan of Rust, but if the only other option is C++, then Rust is the clear winner).
- jeffbee 3y ago
  None of the C stdlib can be used in the kernel, either, and yet the kernel is written in C. Zircon is an existence proof that you can use the C++ std library in a kernel. Do they use every damned thing in std? No, but they do use array, pair, unique_ptr, iterators, and more.
  - SAI_Peregrinus 3y ago
    > None of the C stdlib can be used in the kernel, either, Except the bits allowed in a freestanding environment and (stretching the definition of "used in") the "nolibc" partial C standard library the kernel includes for environments that don't have any other libc available (`tools/include/nolibc`, mostly used for kernel tests where there's no userspace at all).

dale_glass 3y ago

C++ even today has plenty footguns that will make code unsafe, and some of the safety comes at performance costs, or uses features that are ill-suited for the kernel.

b20000 3y ago

there is nothing problematic about memcpy, the problem is that you need to know what you are doing and rust won’t solve that problem.

deleted 3y ago
[deleted]

jeroenhd 3y ago

It took C++ decades to get good, in my opinion. If the kernel team had switched to C++ decades ago, we probably would've ended up with a worse kernel code base. For me, C++11 and C++14 created the modern C++ that's actually usable, but compilers took a while to implement all those features (efficiently and correctly). I find the C++ equivalent of the Rust iterators and such to be even harder to read (almost an accomplishment, given the density of Rust code); I don't think features like ranges would be expressed more succinctly using std::range the same way it can be done in Rust, for instance. I also find C++'s iterators' API design rather verbose, and I don't think there's much good to be said of implementing generics through C++ templates. There are good reasons for why the language was designed this way, but I get the impression succinctness didn't seem to be a primary objective designing them. Rather, I get the feeling that the language designers prioritised making the features accessible to people who already knew C++ and were used to the complexer side of C++.

akira2501 3y ago

> the recalcitrance of reflexive C++ haters. I don't reflexively hate C++, just all the implementations of it.

tialaramex 3y ago

Crucially, the Rust for Linux people proposed to do the work to make Rust for Linux. Whenever we see this complaint from C++ people their idea is basically "LOL, Linus should rewrite kernel to be suitable for C++" and the answer is No. That's not going to happen. Once you refuse their fantasy "Don't lift a finger" way to add C++, they lose interest.