2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."
"There was an interesting debate at the SIGPLAN conference in that period--about the relative need for optimization. It was put on the table that it wasn't going to be needed anymore! So. Anyway. You can have your own opinion on that, but I know I have mine, beyond a doubt that it was a huge setback for--in my opinion--languages and compilers--and the ability to deliver performance--easily--to the user."
Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.
In the real world we've pissed away 30 years of hardware improvements primarily through switching to higher level languages. In the real world higher level languages are still not used we're performance counts (like games). In the real world low level languages like c and C++ are still powering our most important and fundamental projects.
Source, replacing GUI and distributed applications written in C and C++ with managed languages (AOT and JIT) for the last 20 years.
I also happen to remember languages like Fortran and Ada do exist.
Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.
<sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm>
That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).
True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model.
OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG
The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity.
We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.
It was subpar compared to the state of the art then. It's redeeming quality was that it worked on the PDP-11, whereas the better languages required mainframe level resources. The tragedy isn't that C was invented, it fitted it's niche back then. The tragedy is that as HW evolved the world remained stuck with C rather than switching to better languages.
The tragedy wasn't that C was invented, it was fit for purpose then. The tragedy was that as HW evolved beyond the PDP-11 level, unix programming remained stuck at C.
C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.
Just marketing speak.
There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least.
Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.
So port your compiler, figure out a syscall interface on your CPU, patch it into unix/libc and compile them, and.. it's not like that's a small amount of work but it's way easier than bootstrapping any other environment from scratch on a new architecture.
There's surely some amount of historical accident here as well, but no other language/OS combo ran on like 12 different architectures in the 80s.
That's not true. The language is full of footguns, from its basic expressions (signed overflow, integer division-by-zero, and read-before-write are all undefined behaviour) up to concurrency (data-races are undefined behaviour) and everything in between (unsafe arrays, unsafe memory management, alignment, the list goes on). The high-level constructs in modern C++ help, but you're never further than one misstep from undefined behaviour.
Even high-profile codebases by highly skilled teams using all the modern tools, still run into trouble. Even Chromium has security issues arising from the dangers of C++. The push for Rust is out of pragmatism, not trend-chasing or theoretical purity.
Of course, C codebases like the Linux kernel also continue to have these issues.
https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...
As for Windows, The Russians exploited a logical bug in kernel for privilege escalation.
Rust also doesn't prevents overflows, DoS, UaF, OOB.
For example, see CVE-2018-1000657
Another dangerous thing about Rust is Crates. Crates doesn't audit packages for malware and you will face far worse than NPM like situation in future.
Right, but that's not the goalpost we're discussing. We're talking about languages that can guarantee safety - the absence of undefined behaviour - not languages that can fully guarantee correctness (e.g. SPARK).
> Rust also doesn't prevents overflows, DoS, UaF, OOB.
In Rust, integer overflow does not cause undefined behaviour. In Safe Rust, undefined behaviour cannot arise from buffer overflows, use-after-free, or out-of-bounds array access. Safe Rust precludes all undefined behaviour, after all. Unsafe Rust may be 'more safe' than C++ in degree, but not in category: it's an unsafe language, as you say.
> Another dangerous thing about Rust is Crates.
Again, sure.
Source please?
I ask this since Rust doesn't have a formal specification and I can't keep up with it's inner changes.
It did cause undefined behavior in my case but that was 4 years ago.
Safe Rust really is a safe language. That's really what's remarkable about Rust: it has high ambitions for safety and usability and performance, and it's succeeding in achieving them.
(I hear there are some who want to dilute the safety guarantees of Safe Rust. I'm optimistic that they will continue to be ignored.)
[0] https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
Your doc also says this.
> I hear there are some who want to dilute the safety guarantees of Safe Rust
Unfortunately, I don't use Rust at work. I can't talk about it anymore, either. I can't use an informal reference to reason about its actual behavior. At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language. C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely.
Rust seriously need to add Function Overloading, Generics.
I don't follow here. You can do that. There's a more formal reference too though. [0]
> Relying on integer overflow’s wrapping behavior is considered an error
Good point, I'd missed that. So, Rust strongly discourages relying on the wrapping behaviour of release builds. It seems to take the opposite approach that Java uses.
In Java, you get wrapping arithmetic 'by default' (i.e. when using the arithmetic operators), and there are special functions that give throw-on-overflow behaviour (which almost no one uses). [1] In Rust, the arithmetic operators handle overflow either by wrapping or by panic, depending on build configuration, and if you deliberately want to overflow, there are special functions for that (i32::wrapping_add) which behave identically on Debug and Release builds.
I believe Ada does something similar.
> At the end of the day, C++ puts food on the table. I try to improve C++ as much as possible, knowing that it is an imperfect language.
Sure, I use C++ too. I really only know about Rust from a distance, I'm not a Rust programmer. C++ still has considerable advantages: excellent first-class support on all major platforms, a wealth of libraries available, mature tooling (static analysis, dynamic analysis, top-notch IDEs). Of course, some major software frameworks are natively C++, so you're strongly encouraged to stick with C++ (Qt, Direct3D).
> C++ is heading into safe direction, and I'm sure C++26 will be able to provide more features to write code safely.
The C-style footguns will probably still be there in 20 years. Yes, they've given us std::vector and std::array which allow us to manage arrays more safely than raw C arrays, but read-before-write is still undefined behaviour, dereferencing null is still undefined behaviour, divide-by-zero is still undefined behaviour. They gladly add more functionality to the standard library, but they're very reluctant to tweak the core of the language. At least we have two's complement guaranteed by the C++ standard now.
> Rust seriously need to add Function Overloading, Generics.
I wasn't aware Rust lacked generics. That sounds frustrating.
I have mixed feelings on function overloading. It makes it harder to reason about what function is being called.
[0] https://doc.rust-lang.org/reference/behavior-not-considered-...
[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base...
You rarely do these in Modern C++.
It's your responsibility to check the input of program before doing anything with it.
Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null
> The C-style footguns will probably still be there in 20 years.
It's your job to know these footguns. Actually, it will take 2-3 months for a new programmer to separate C++ and C and understand what Modern C++ actually about.
> I have mixed feelings on function overloading. It makes it harder to reason about what function is being called.
It doesn't because overloading depends on the arguments not on the function names
Without overloading, things become ugly.
As I said before, one way or another, undefined behaviour is still a major problem in C++ codebases. This isn't really up for debate. pjmlp provided a good link on this. Most of Chromium's serious security bugs are due to memory safety issues. [0]
> It's your responsibility to check the input of program before doing anything with it.
C++ makes it the programmer's responsibility to avoid undefined behaviour. Programmers are not capable of doing this reliably. We're now at the point that it's no longer credible to argue otherwise. Even after all these decades it's still a problem for C++.
> Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null
Sure, and with GCC/Clang, there are equivalent flags to enable trap-on-error for these errors. They're rarely used in production though, so we still face the consequences of undefined behaviour.
> It's your job to know these footguns.
Again, we've seen that C and C++ programmers simply are not capable of avoiding undefined behaviour. Even Google is unable to keep UB out of their prized Chromium codebase, despite their considerable investment.
> It doesn't because overloading depends on the arguments not on the function names
That's the definition of overloading, not a refutation of my point.
In a language like C with no overloading, the function identifier is enough to uniquely identify the function. You don't need to check if there are overloads, the identifier is enough. If you introduce overloading, that property no longer holds. You might work under the mistaken impression there are no other overloads of a function, or it might be non-trivial to determine the types being passed, especially in the presence of type-inference.
It's resolved at compile time, rather than at runtime, but my point stands.
> Without overloading, things become ugly.
It's a tradeoff.
Here is a real world logical exploit that knock sandbox and Rust won't prevent this stuff,
https://bugs.chromium.org/p/chromium/issues/detail?id=386988
The quote was Around 70% of our high severity security bugs are memory unsafety problems. Doesn't sound like sandboxing is effective there.
> Here is a real world logical exploit that knock sandbox and Rust won't prevent this stuff,
I'm not sure I see your point here. No one is arguing that Safe Rust makes all logic bugs go away. It's not a formal methods framework, it's a safe programming language. If Chromium had been written in Safe Rust (assuming that's practical), presumably at least 70% of its high-severity security bugs would have been avoided.
You're right that they still wouldn't have perfection. The only shot at perfect security is through formal methods, following SeL4, but as things stand, formal methods cannot scale to a problem as large as a modern web browser. Sadly, even TLS is beyond what we can implement with formal methods.
This quote simply means there are 70% high severity security bugs and it doesn't implies anything about sandbox.
You can have a use-after-free exploit but it's worthless without a sandbox escape.
Sandboxing is very effective at memory bugs but certainly bad at logical bugs.
Chromium is a good example actually, I bet they would rather follow the "Custom C++ libraries" and "Hardware mitigations" than the Firefox approach.
https://www.chromium.org/Home/chromium-security/memory-safet...
Apple did something similar recently, their iBoot firmware uses a custom safe C dialect.
> The Chromium project finds that around 70% of our serious security bugs are memory safety problems.
I'll point to this next time this topic crops up.