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
by Anonymous Coward writes:
on Saturday April 17, 2021 @03:14PM (#61284466)
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.
Systems should be designed to minimize the amount of care required to write software such that "just don't make mistakes" is actually achievable. This can't be done at the compiler level alone. It requires development of specialized high level contractual languages to define and impose appropriate constraints on the programmer.
> 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 set
In many case you can add compile time checks to C. This is possible. Rust was inspired in large part by a safe variant of C (cyclone). For other cases, you can have very cheap run-time checks, which you could opt out for extremely performance sensitive parts (which almost do not exist). We mostly miss good C compiler that add compile-time and run-time safety features (but things are improving) and some language annotations.
When you make your mark in the world, watch out for guys with erasers.
-- The Wall Street Journal
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:Spot on... (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 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.
Systems should be designed to minimize the amount of care required to write software such that "just don't make mistakes" is actually achievable. This can't be done at the compiler level alone. It requires development of specialized high level contractual languages to define and impose appropriate constraints on the programmer.
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: (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 set
Re: (Score:2)
In many case you can add compile time checks to C. This is possible. Rust was inspired in large part by a safe variant of C (cyclone). For other cases, you can have very cheap run-time checks, which you could opt out for extremely performance sensitive parts (which almost do not exist). We mostly miss good C compiler that add compile-time and run-time safety features (but things are improving) and some language annotations.