> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago.

The core of the borrow checker was being formulated in 2012[1], which is 13 years ago. No infeasibility then. And it's based on ideas that are much older, going back to the 90s.

Plus, you are vastly overestimating the expense of borrow checking, it is very fast, and not the reason for Rust's compile times being slow. You absolutely could have done borrow checking much earlier, even with less computing power available.

1: https://smallcultfollowing.com/babysteps/blog/2012/11/18/ima...

> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago.

IIRC borrow checking usually doesn't consume that much compilation time for most crates - maybe a few percent or thereabouts. Monomorphization can be significantly more expensive and that's been much more widely used for much longer.

> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time.

I think you're setting the bar a little too high. Rust's borrow-checking semantics draw on much earlier research (for example, Cyclone had a form of region-checking in 2006); and Turbo Pascal was churning through 127-character identifiers on 8088s in 1983, one year before C++ stream I/O was designed.

EDIT: changed Cyclone's "2002" to "2006".

I remember, I was there in the 1980's coding, hence why I know C and C++ were not the only alternatives, rather the ones that eventually won in the end.

> the processor, which is a glorified, hardware implemented PDP-11 emulator.

This specific seems like just gratuitously rewriting history.

I can get how you'd feel C (and certain dialects of C++) are "closer to the metal" in a certain sense: C supports very few abstractions and with fewer abstractions, there are less "things" between you and "the metal". But this is as far as it goes. C does not represent - by any stretch of imagination - an accurate computational model or a memory of a modern CPU. It does stay close to PDP-11, but calling modern CPUs "glorified hardware emulators of PDP-11" is just preposterous.

PDP-11 was an in-order CISC processor with no virtual memory, cache hierarchy, branch prediction, symmetric multiprocessing and SIMD instruction. Some modern CPUs (namely the x86/x64 family of CPUs) do emulate a CISC ISA on that is probably more RISC-like, but that's as far we can say they are trying to behave like a PDP-11 (even though the intention was to behave like a first-gen Intel Pentium).

> we shall not forget that all processors are C VMs

This idea is some 10yrs behind. And no, thinking that C is "closer to the processor" today is incorrect

It makes you think it is close which in some sense is even worse

Checking of whole-program invariants can be accurate and done basically for free if the language has suitable semantics.

For example, if a language has non-nullable types, then you get this information locally for free everywhere, even from 3rd party code. When the language doesn't track it, then you need a linter that can do symbolic execution, construct call graphs, data flows, find every possible assignment, and still end up with a lot of unknowns and waste your time on false positives and false negatives.

Linters can't fix language semantics that create dead-ends for static analysis. It's not a matter of trying harder to make a better linter. If a language doesn't have clear-enough aliasing, immutability, ownership, thread-safety, etc. then a lot of analysis falls apart. Recovering required information from arbitrary code may be literally impossible (Rice's theorem), and getting even approximate results quickly ends up requiring whole-program analysis and prohibitively expensive algorithms.

And it's not even an either-or choice. You can have robust checks for fundamental invariants built into the language/compiler, and still use additional linters for detecting less clear-cut issues.

If the compiler is not checking them then it can't assume them, and that reduces the opportunities for optimizations. If the checks don't run on the compiler then they're not running every time; if you do want them to run every time then they may as well live in the compiler instead.

> And yet, they both still suffer from the flaw that the parent comment cites.

I dunno; the flaw is not really comparable, is it? The skill and discipline required to write C bug-free is an orders of magnitude less than the skill and discipline required to write C++.

Unless you read GGPs post to mean a flaw different to "skill and discipline required".

Sending out a strong disagree from the embedded systems world. C is king here.

(Broad, general, YMMV statement): The general C++ arc for an embedded developer looks like this:

1.) discover exceptions are way too expensive in embedded. So is RTTI.

2.) So you turn them off and get a gimped set of C++ with no STL.

3.) Then you just go back to C.

Right on the money!

Other then hardcore embedded guys and/or folks dealing with legacy C code, I and most folks i know almost always use C++ in various forms i.e. "C++ as a better C", "Object-Oriented C++ with no template shenanigans", "Generic programming in C++ with templates and no OO", "Template metaprogramming magic", "use any subset of C++ from C++98 to C++23" etc. And of course you can mix-and-match all of the above as needed.

C++'s multi-paradigm support is so versatile that i don't know why folks on HN keep moaning about its complexity; it is the price you pay for the power you get. It is the only language that i can program in for itty-bitty MCUs all the way to large complicated distributed systems on multiple servers plus i can span all of applications to systems to bare-metal programming.

> Have you written significant amounts of C or C++?

Yes.

> Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features.

Those "someone's" have not written a significant amount of C. Maybe they wrote a significant amount of C++.

The cognitive load when dealing with C++ code is in no way comparable to the cognitive load required when dealing with C code, outside of code-golfing exercises which is as unidiomatic as can be for both languages.