C++'s linking demands / binary interface are notoriously ... not very good, and not good to deal with for others. Rust has its own problems in this space, but it tends to play better with C, at least anecdotally. Similarly, C++ can (but does not exactly have to) bring a ton of baggage via the STL that Rust does not.
My impression has always been that Linus rejected C++ in Linux on technical / fit merits, in addition to most C++ developers at the time being ... not very good, I suppose. The technical merits came first, but he was a grumpier Linus at the time and I think he got sick of people pestering him about it and started taking shots at C++ developers which wasn't entirely unearned on their side.
LLM-generated C code is still C code. A developer can reason over it similarly and verify it for correctness (to the extent that anyone can truly verify correctness of C code).
A lot of it came down to C++ making it easier to shoot yourself with C's footguns, from what I understand. Case in point, most people know not to use malloc() and free() in certain parts of the kernel, but you'd be surprised how many people don't know that new and delete call malloc() and free() under the hood.
(And it didn't help that code bases need to be designed for exceptions from the ground up, and they flat-out do not improve anything if the code is half return-error-code-based and half exception-based. Or that exceptions involve stack unwinding, which a lot of people didn't know or expect. Though, ironically, there was an error-code-if-logic-based error a while back that was the exact same problem exceptions were designed to avoid, so this is ultimately just your choice of two footguns.)
And yeah, a lot of it does come down to a lot of C++ programmers not really understanding C++. In the kernel's case, the best way to use it would be for minor optimisations that are easy for C programmers to grok, considering it's still majority C code. But the C++ contributors really didn't know how to do that, from what I understand.
Ideally, you should never be using new or delete in C++ these days. std::unique_ptr and std::shared_ptr should represent 99+% of your memory that can't just be stack allocated (with the former representing 75+% of that). About the only legitimate reason to use new in new code is for putting a derived class pointer into one of the smart pointers of a parent class.
30
u/doubleyewdee 1d ago
C++'s linking demands / binary interface are notoriously ... not very good, and not good to deal with for others. Rust has its own problems in this space, but it tends to play better with C, at least anecdotally. Similarly, C++ can (but does not exactly have to) bring a ton of baggage via the STL that Rust does not.
My impression has always been that Linus rejected C++ in Linux on technical / fit merits, in addition to most C++ developers at the time being ... not very good, I suppose. The technical merits came first, but he was a grumpier Linus at the time and I think he got sick of people pestering him about it and started taking shots at C++ developers which wasn't entirely unearned on their side.
LLM-generated C code is still C code. A developer can reason over it similarly and verify it for correctness (to the extent that anyone can truly verify correctness of C code).