31–40 of 56 posts
C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large projects move forward.
What’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large proje…
With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example.
> don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding.
Indeed you don't know what you're talking about. Adopting a style guide is not the same thing as joining a cult.
C++ has been in active use for around 30 years, and modern C++ for over a decade. People use it just fine, and don't feel the need to evangelize. Other communities sadly still appear to feel a constant need to reassure and convince themselves they didn't made the wrong choice.
What’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large proje…
Benefits of C++ over Rust: - Far easier and nicer to integrate with an enormous existing C codebase - C semantics are much more similar to C++ than to Rust, so no need to do huge pattern redesigns - No need to suddenly fight a borrow checker and prove lifetimes for a code base that isn't aware of them at all - Interfacing with existing C code will require unsafe interop, which greatly reduces the benefit of Rust's primary selling point - Transitions to C++ code will counterintuitively almost certainly introduce less bugs than rewriting in Rust, because you can do it in a much more piecemeal manner, and only do so in very disciplined way
Why should they rewrite it in Rust?
What’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large proje…
"Kernel C" is the name given to the subset of C (read, Linux's flavor of C) that was formed by deciding which language features/compiler extensions they would/wouldn't use. Hardly a new or unsolvable problem. Benefits of C++ over Rust: - Far easier and nicer to integrate with an enormous existing C codebase - C semantics are much more similar to C++ than to Rust, so no need to do huge pattern redesigns - No need to s…
This isn't a bad thing. Failing to compile when there is a memory error is better than leaving it in to later manifest as a mysterious crash or be found by a fuzzer or an attacker. When programming without a borrow checker you have to be the borrow checker yourself. People being their own borrow checker does not scale.
Earlier quoted context omitted.
Won’t you end up with mostly _unsafe_ code this way?
It really depends. If the interface that you're wrapping can have a nice, abstract API (like "parse this JPEG header into a struct" or something), then the hope is that you can figure out how to express that API in safe Rust, even though underneath it might be a big pile of C. The trouble is when there is no clean API boundary that can fit within safe Rust's rules, like when the underlying C code is "object soup" whe…
This is actually not what you want, because as a rule Safe Rust enforces the use of Rust references which have stricter requirements than C++ references or C/C++/Rust raw pointers, and will otherwise introduce UB. (See the Rustonomicon for a detailed description of those requirements.) A "safe Rust" API is OK when all callers can be proven to satisfy these requirements, otherwise raw pointers are easier even though they must be accessed in an unsafe block.
There are also pitfalls when passing arguments by value to Safe Rust, e.g. a `bool` value MUST be 0 or 1, an `enum` MUST not have an invalid discriminant etc. Breaking any of these requirements when calling Safe Rust from C/C++ makes instant UB a very real possibility.
The path to migrate to Zig is, or would be, the most straightforward, except that that language is not ready. But in design terms it's definitely got the things the OP is championing C++ for, and a better story for actually addressing longstanding systems programming issues instead of heaping stuff onto the C toolchain and therefore making everyone debug C build-time errors.
The reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and..…
(I've heard plenty of complains about Rust syntax, so I'm less so interested in that than what C++ syntax gets right. Unless it's just a familiarity thing...)
What’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large proje…
> Rust actually is a nice language. C++ requires deciding which features to use? With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example. > don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only…
What’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large proje…
"Kernel C" is the name given to the subset of C (read, Linux's flavor of C) that was formed by deciding which language features/compiler extensions they would/wouldn't use. Hardly a new or unsolvable problem. Benefits of C++ over Rust: - Far easier and nicer to integrate with an enormous existing C codebase - C semantics are much more similar to C++ than to Rust, so no need to do huge pattern redesigns - No need to s…
Also, the interop story with rust is equal or better than C++ in many areas at this point. Aside from tools like bindgen eliminating entire families of footguns, try doing something like registering a member function to a c callback, the way virtually every driver works. The rust equivalent in the extremely immature kernel dev trees are a bit ugly, but already much simpler than the idiomatic C++ equivalents. For additional fun, try and do it safely with a custom allocator or closures in a modern version.
> We do a lot of metaprogramming in the Linux kernel, implemented with some often truly hideous macro hacks. If you do a lot of meta-programming… why not used a more principled approach like Lex & Yacc? Why not go all the way to design mini-languages and compile them to C? Or design C extensions and compile them to C? You can still have good debugging support with line markers. https://gcc.gnu.org/onlinedocs/cpp/Prep…
The path to migrate to Zig is, or would be, the most straightforward, except that that language is not ready. But in design terms it's definitely got the things the OP is championing C++ for, and a better story for actually addressing longstanding systems programming issues instead of heaping stuff onto the C toolchain and therefore making everyone debug C build-time errors.
The reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and..…
&&auto my_closure = [&](int x, int y) { return x + y }
let my_closure = |x: int, y: int| { x + y }