4 ms·

> But I'm hard pressed to imagine how a C++ style that avoids vtables like the plague could really have that much to offer over straight C. unique_ptr / shared

> But I'm hard pressed to imagine how a C++ style that avoids vtables like the plague could really have that much to offer over straight C. unique_ptr / shared_ptr alone would be a massive upgrade over straight C. Simply being able to enforce ownership would be huge. So would just having namespaces. Things like move semantics, static_assert, and constexprs would then be the cherry on top. There's also public/private fields, friend classes, etc... to keep people from accidentally poking things they shouldn't be. C++ is so very much not just "C with vtables." But C++ has a reputation, deserved or not, for being overly complex. And ultimately Linus chose the devil he knew over something that by all accounts would have been better. Nearly every other large C project has moved into C++, even from other staunch defenders of C like John Carmack eventually relented that C++ was better for large teams. Rust gets to hit the reset button here with a fresh reputation (and some extra safety & cool tricks), and Linus' views may have changed over time.

tialaramex 5y ago
C++ has a bunch of principles that Linus disagrees with. Actually some important C++ people aren't sold on them either, but too bad, they are principles of C++ and so you're stuck with them in C++. Examples include exceptions as the one true error mechanism, and the use of implicit allocation. Rust doesn't have the former, and Rust's core doesn't have the latter (but std does), one of the stipulations from Linus when this began was that Rust for Linux needed to ensure it didn't sneak in implicit allocation. Thus, while a beginner's Rust program might have text += "Some more stuff"; you won't see that in the kernel -- because it won't compile, the core::ops::AddAssign isn't implemented on these string types in the kernel because it's implicit allocation. As to move, the move semantics in C++ are really awkward. They're a nice optimisation of course, which is why they're provided, but you would not deliberately do it that way in a language which had move semantics from the outset, as demonstrated by Rust. To make move work with existing C++ software it has to "hollow out" objects when they're moved from. Rust needn't do that, if you move a Foozle from var1 to var2 in C++, it must carefully hollow out the Foozle in var1, because in C++ var1 will eventually get destroyed, so its contents must be valid and safe to destroy. If you move the same Foozle from var1 to var2 in Rust, the Rust compiler knows you moved it, so, it's gone, var1 won't get destroyed and no further attention to it is needed.
- kllrnohj 5y ago
  > Examples include exceptions as the one true error mechanism, and the use of implicit allocation. -fno-exceptions is very widely used and non-throwing variants of basically everything exist as a result. That's not a reason to avoid C++ in the kernel as a result. Especially with how heavily Linux already relies on GCC C extensions, there's obviously no hangups on being "strictly standard compliant." Not have exceptions ever been C++'s "one true error" mechanism ever. For example see iostream: https://www.cplusplus.com/reference/ios/ios/rdstate/ https://www.cplusplus.com/reference/ios/ios/rdstate/ C++ is not, and never has been, anywhere near that dogmatic. As for the rest of your points, you seem to be arguing Rust is better than C++. But that's not really relevant to why C++ was rejected before Rust even existed. I do think Rust is even better than C++, but I also think C++ is a huge improvement over C, especially for large codebases.
  - tialaramex 5y ago
    It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. However whereas you can write -fno-exceptions and get a C++ with this core language feature excised, you can't do the same for implicit allocation. In contrast the Rust for Linux team have worked hard to produce a Rust for Linux environment that doesn't panic!() and has no implicit allocation, since these are red lines for Linus.
    - kllrnohj 5y ago
      > It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. You're still trying to force C++ to be dogmatic. It never has been. It's always tried to be accommodating to all types of usages. It's always been multiparadigm. 'new' wasn't even defined to throw std::bad_alloc until C++98, which also introduced 'std::nothrow_t' to have it return null instead. > you can't do the same for implicit allocation Just like with exceptions this really isn't true, either. There's no implicit allocations in the core language, only in the STL. Saying that the "new" operator does implicit allocation is like saying "malloc" does implicit allocation. Regardless, placement new has always existed, and the non-placement 'new' operator has always been overridable. And all of the STL is optional & replaceable.

tialaramex 5y ago

C++ has a bunch of principles that Linus disagrees with. Actually some important C++ people aren't sold on them either, but too bad, they are principles of C++ and so you're stuck with them in C++. Examples include exceptions as the one true error mechanism, and the use of implicit allocation. Rust doesn't have the former, and Rust's core doesn't have the latter (but std does), one of the stipulations from Linus when this began was that Rust for Linux needed to ensure it didn't sneak in implicit allocation. Thus, while a beginner's Rust program might have text += "Some more stuff"; you won't see that in the kernel -- because it won't compile, the core::ops::AddAssign isn't implemented on these string types in the kernel because it's implicit allocation. As to move, the move semantics in C++ are really awkward. They're a nice optimisation of course, which is why they're provided, but you would not deliberately do it that way in a language which had move semantics from the outset, as demonstrated by Rust. To make move work with existing C++ software it has to "hollow out" objects when they're moved from. Rust needn't do that, if you move a Foozle from var1 to var2 in C++, it must carefully hollow out the Foozle in var1, because in C++ var1 will eventually get destroyed, so its contents must be valid and safe to destroy. If you move the same Foozle from var1 to var2 in Rust, the Rust compiler knows you moved it, so, it's gone, var1 won't get destroyed and no further attention to it is needed.

kllrnohj 5y ago
> Examples include exceptions as the one true error mechanism, and the use of implicit allocation. -fno-exceptions is very widely used and non-throwing variants of basically everything exist as a result. That's not a reason to avoid C++ in the kernel as a result. Especially with how heavily Linux already relies on GCC C extensions, there's obviously no hangups on being "strictly standard compliant." Not have exceptions ever been C++'s "one true error" mechanism ever. For example see iostream: https://www.cplusplus.com/reference/ios/ios/rdstate/ https://www.cplusplus.com/reference/ios/ios/rdstate/ C++ is not, and never has been, anywhere near that dogmatic. As for the rest of your points, you seem to be arguing Rust is better than C++. But that's not really relevant to why C++ was rejected before Rust even existed. I do think Rust is even better than C++, but I also think C++ is a huge improvement over C, especially for large codebases.
- tialaramex 5y ago
  It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. However whereas you can write -fno-exceptions and get a C++ with this core language feature excised, you can't do the same for implicit allocation. In contrast the Rust for Linux team have worked hard to produce a Rust for Linux environment that doesn't panic!() and has no implicit allocation, since these are red lines for Linus.
  - kllrnohj 5y ago
    > It's true that despite the fact exceptions are the one true C++ error handling mechanism in fact lots of C++ programmers religiously never use them. That ought, one would think, to set alarm bells ringing. And it does for the C++ Committee. Language schism is bad news. You're still trying to force C++ to be dogmatic. It never has been. It's always tried to be accommodating to all types of usages. It's always been multiparadigm. 'new' wasn't even defined to throw std::bad_alloc until C++98, which also introduced 'std::nothrow_t' to have it return null instead. > you can't do the same for implicit allocation Just like with exceptions this really isn't true, either. There's no implicit allocations in the core language, only in the STL. Saying that the "new" operator does implicit allocation is like saying "malloc" does implicit allocation. Regardless, placement new has always existed, and the non-placement 'new' operator has always been overridable. And all of the STL is optional & replaceable.