I'm a long-time C++ programmer, but I don't exactly get "triggered" by whatever Linux says about C++. We've all long known he has a bug up his ass about C++, after all. I disagree that it's a "crap" language, but anyone who has worked with it can easily see it has a huge number of flaws. Ironically, many of those flaws are there because C++ strives to remain mostly compatible with C and legacy C++ code, which makes it easy to do the wrong thing even if there are more modern ways of solving common problem
It's easy to forget how ridiculously old the language is. Why replace one ancient language with another not-quite-as-ancient language?
Age is irrelevant.
Rust, in contrast, forces you to specifically opt-out of memory safety, which ensures you only do it when absolutely necessary
It ensures no such thing.
, ensuring a smaller footprint of unsafe code to review. It makes more sense, if you're going to switch languages, to use a more modern language that definitely solves memory safety, which some surveys have shown accounts for roughly 70% of security bugs.
Important not to oversell the value of perfect code with no security bugs. If we could magically snap our fingers and accomplish this tomorrow nothing would change. 90% of all compromises exploit people not systems.
The argument of "just don't make mistakes" or "use better libraries" are just not realistic. All humans make mistakes, and C has serious limitations as a language that still force the onus of safety on the programmer instead of the compiler.
The problem with both Rust and C++ is RAII. While Rust is better in that it does not have exceptions it is also completely incapable of handling allocation failure which is a big deal for system programming.
> The source of safety is rooted in constraints not language. There is no reason similar constraints could not be enforced in C or any other language for that matter to achieve similar results.... > It requires development of specialized high level contractual languages to define and impose appropriate constraints on the programmer
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming langu
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming language - things like don't access array elements that don't exist.
A prime example of why using (only) an enforced-storage-safety language is inadequate for OS development is memory-mapped I/O. These are accessed as if they were a particular fixed-address region of memory - but they're actually registers in an I/O device, or a series of sets of registers in a set of I/O deivces.
The C (and C++) idiom for accessing such registers is to declare a struct of volatile variables with the same layout as the registers - or a vector of such structs if the peripheral has a multiple of identical sets of registers evenly spaced in the address space. Then define a manifest constant with the value of the first address, cast to type "pointer-to-that-struct-type" and use it as if it were such a pointer. The compiler optimizes away the pointer itself but does NOT optimize away the loads and stores - generating efficient code to manipulate the I/O device registers. This idiom is what enabled writing drivers in a compiler language - along with all but a handful of lines of the Unix kernel and later OSes.
Try that with an enforced-storage-safety language and it says "You're trying to use a piece of memory you didn't get from one of my memory allocation mechanisms. So I won't let you do that. Nyah!" (Or it will have a mechanism for bypassing storage safety enforcement for this purpose - which can be used to subvert it for other purposes.)
Spot on... (Score:5, Insightful)
"C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language"
Linus is truly a treasure for succinctly sum things up. I would have left of the "crap language" because that will trigger the faithful.
Re: (Score:5, Interesting)
I'm a long-time C++ programmer, but I don't exactly get "triggered" by whatever Linux says about C++. We've all long known he has a bug up his ass about C++, after all. I disagree that it's a "crap" language, but anyone who has worked with it can easily see it has a huge number of flaws. Ironically, many of those flaws are there because C++ strives to remain mostly compatible with C and legacy C++ code, which makes it easy to do the wrong thing even if there are more modern ways of solving common problem
Re: (Score:-1, Flamebait)
It's easy to forget how ridiculously old the language is. Why replace one ancient language with another not-quite-as-ancient language?
Age is irrelevant.
Rust, in contrast, forces you to specifically opt-out of memory safety, which ensures you only do it when absolutely necessary
It ensures no such thing.
, ensuring a smaller footprint of unsafe code to review. It makes more sense, if you're going to switch languages, to use a more modern language that definitely solves memory safety, which some surveys have shown accounts for roughly 70% of security bugs.
Important not to oversell the value of perfect code with no security bugs. If we could magically snap our fingers and accomplish this tomorrow nothing would change. 90% of all compromises exploit people not systems.
The argument of "just don't make mistakes" or "use better libraries" are just not realistic. All humans make mistakes, and C has serious limitations as a language that still force the onus of safety on the programmer instead of the compiler.
The problem with both Rust and C++ is RAII. While Rust is better in that it does not have exceptions it is also completely incapable of handling allocation failure which is a big deal for system programming.
The source of safety is rooted in constrain
Re: Spot on... (Score:3)
> The source of safety is rooted in constraints not language. There is no reason similar constraints could not be enforced in C or any other language for that matter to achieve similar results. ...
> It requires development of specialized high level contractual languages to define and impose appropriate constraints on the programmer
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming langu
Re: Spot on... (Score:2)
You're proposing using TWO languages. C and another language to define all the safety. There's no need for that. One can put most of the constraints in the programming language - things like don't access array elements that don't exist.
A prime example of why using (only) an enforced-storage-safety language is inadequate for OS development is memory-mapped I/O. These are accessed as if they were a particular fixed-address region of memory - but they're actually registers in an I/O device, or a series of sets of registers in a set of I/O deivces.
The C (and C++) idiom for accessing such registers is to declare a struct of volatile variables with the same layout as the registers - or a vector of such structs if the peripheral has a multiple of identical sets of registers evenly spaced in the address space. Then define a manifest constant with the value of the first address, cast to type "pointer-to-that-struct-type" and use it as if it were such a pointer. The compiler optimizes away the pointer itself but does NOT optimize away the loads and stores - generating efficient code to manipulate the I/O device registers. This idiom is what enabled writing drivers in a compiler language - along with all but a handful of lines of the Unix kernel and later OSes.
Try that with an enforced-storage-safety language and it says "You're trying to use a piece of memory you didn't get from one of my memory allocation mechanisms. So I won't let you do that. Nyah!" (Or it will have a mechanism for bypassing storage safety enforcement for this purpose - which can be used to subvert it for other purposes.)