Lambda the Ultimate

Just reminiscing. There was this guy on my college dorm floor who was really in to airplanes. Maybe a few years before this, the USAF had (iirc) first publicly admitted to experimenting with fighter jets with forward-swept wings, vehicles so unstable that flying them was beyond human reflexes and a computer control system was needed for them to fly at all; very high-tech stuff, very impressive. He had a poster on his dorm room wall of one of those forward-swept-wing fighters, just the sort of thing he would have a poster of. One day in the dorm common room we were watching some miscellaneous fluff on TV (I think it was Airwolf), and the episode that was on involved a crop-dusting triplane. And this guy with a poster of a super-high-tech fighter on his wall remarked reverentially, "You can fly one of those at thirty miles an hour without stalling." [The speed he named may actually have been lower than that; what I've remembered vividly all these years is the referential tone in which it was said.]

I think the standards process for C has a lot to with it. It's not perfect, and there are ambiguities around some (important) edge cases, but it's a sterling effort by many fine minds.

It'll be a long time before SQLite could be ported and reach the same level of reliability and predictability.

Duplicate post edited for brevity. Please ignore.

The thing I note about C code is that if something goes wrong (and it does, a lot) there is always a way to debug the code. You can track down the bug, and whatever it happens to be this time, you can always fix it. The basic libraries leave a lot of things undone, but you can choose to do them any way you need them done for a particular use. And the language definition and the library definitions are remarkably stable.

Over time, the bugs in C code can get fixed, and when the effort is put in to do it right, and check the state of the relevant ambiguities and differences and definitions and conditions and handle each case, the bugs STAY fixed.

Legacy code that's been ported from an ancient VAX through seven generations of other systems with different Operating Systems from different vendors with different word lengths and endianness and and I/O primitives and distinctions between character and block devices, and compilers from five different sources, etc, may be a massive hairball but all that hair works out and checks all those corner cases and differences, and good fixes continue to work those corner cases and differences out through all future versions of C. Which means legacy code eventually becomes as close to bulletproof as anything has ever been.

With most languages this isn't the case. Small bugs that affect rare corner cases get baked into the extended runtime, or the memory management functions, or the interrupt handling, or the I/O libraries, or whatever else. Design decisions not compatible with at least a few of the things you want to do are made fundamental and mandatory and no other way to do those things is available. Language definitions changes between versions 4 and 5 invalidating all code written in versions 1 and 2 and there's no way to check what version of the interpreter it's using. Furthermore there's often no way to achieve interaction with the underlying system in a way that's design-compatible with the earlier versions. Libraries with OO implementations get "ripple effect" bugs when the OO systems they're implemented in get reimplemented upstream. And the compiler or interpreter tends to be available from exactly one source. If that's the case, and that source decides not to continue, the language dies.

So either the languages themselves are too limited (usually for the sake of "safety" or "simplicity"), or they contain lexical and semantic ambiguities you can't check for and bugs due to confusion or ambiguity about implied and undeclared object types with different overloaded operations or operands (usually for the sake of "ease of use" or "brevity").

It's all well and good to have some definition of "Type safety" but if you achieve overloaded functions that are truly invisible in application you invite confusion on the programmer's part while proving that there is never confusion on the compiler's part. It doesn't matter if the types are "safe" if the syntax leads someone to believe the semantics that apply to them are those of a different type. Especially if scope or overloading rules change, no matter how subtly, between versions.
the code you write in those languages is unstable and will eventually break with no reliable way to diagnose, check for the conditions relevant to the bug, and permanently fix it.

After coding the EROS kernel in C++, we switched to C for its successor. There were three reasons for the switch:

1. The EROS kernel threw *no* exceptions, but we paid a 30% performance penalty due to reduced iCache utilization because of exception handler code that could never be reached.
2. Static model checking on languages that encourage opaquely indirected procedure calls (as in virtual functions) are much harder - the required conservative assumptions rapidly compromise useful results.
3. The reduction in "helpful abstraction" made it much easier to understand what the code was actually going to do on the machine. In a security kernel, that's critical.

I've said we didn't use exceptions, but we also didn't use inheritance. Given this, essentially none of the C++ features had any value for us.

The main thing we lost was a weaker sequence point specification, which wasn't a big issue for this particular code.

After coding the EROS kernel in C++, we switched to C for its successor. There were three reasons for the switch:

1. The EROS kernel threw *no* exceptions, but we paid a 30% performance penalty due to reduced iCache utilization because of exception handler code that could never be reached.
2. Static model checking on languages that encourage opaquely indirected procedure calls (as in virtual functions) are much harder - the required conservative assumptions rapidly compromise useful results.
3. The reduction in "helpful abstraction" made it much easier to understand what the code was actually going to do on the machine. In a security kernel, that's critical.

I've said we didn't use exceptions, but we also didn't use inheritance. Given this, essentially none of the C++ features had any value for us.

The main thing we lost was a weaker sequence point specification, which wasn't a big issue for this particular code.

It is an open but unresolved question whether Rust would be better or safer for this code base.

Opaquely indirected function calls seem worse and worse the more I deal with code that uses them. ESPECIALLY overloaded operators that invite the programmer to think s/he knows what the code means when it means something completely different.

[Redacted: nightmare story about overloaded "+" intended for array mathematics being called in place of overloaded "+" intended for string concatenation, uncaught because both were stored as byte vectors of compatible underlying type as seen by the third-party GPU library that redefined "+" when nobody was looking, resulting in strings of binary garbage emerging from unchanged code that was working a few days prior. It would have been much worse if it had been the other way, because a byte vector interpreted as the (numeric) result of array mathematics isn't as obviously garbage.

Operator overloading, at least in forms seen so far, is BAD. ]

That's an example of exactly the kind of thing I was talking about. Features baked into the extended runtime (like opaque indirected procedure calls) make the semantics much harder to check and verify, and impose a penalty in stack memory management overhead, Not to mention compiler time and optimization efficiencies lost where things can't be proven.

Even if your code doesn't use them. I know people claim about C++ that it imposes no overhead greater than C code. But the C++ runtime environment has to support things the C runtime environment doesn't.

Even if the code you write is just C and runs at the same speed, that runtime environment you're linking it to is bigger, heavier, and a bit slower. Even if the code you write is just C, the C++ compiler can't optimize it as tightly because the C++ compiler has to assume the worst about what, in a C++ environment, could *POSSIBLY* be in some other file of code and change the meaning of the code it's looking at.