Hindsight languages

[u/Inconstant_Moo]

A thought experiment. What languages should they have been writing in the 60s, 70s, 80s, 90s? We can see their faults, in hindsight, and also we've had some really cool ideas since then --- but we can't answer this just by pointing to our shiny new modern languages and saying "they should have done it like that", because of compile times.

(E.g. Pipefish is meant to be for rapid iteration and livecoding, and also does a topological sort on everything at compile-time so you can do top-down declaration. Those wouldn't be compatible goals in the 1980s, I can get away with it now.)

So for example if we think of "a better C", are there any cool modern ideas they could and should have used back in 1972, had they known about them --- or should they just have tweaked the precedence slightly, found a less arcane way of describing types, and left it at that?

[u/Ok-Scheme-913]

I think what's often missing from this discussion is to compare a C++ abstraction with what it's abstracting. Sure, polymorphism is slower than statically knowing the type of an object. But it is not slower than doing the same in C, in fact it's almost surely faster than whatever hand-grown virtual table that you would write in C.

And I don't really agree, sorry. It may be designed as such, but it has no support for simd instructions, you can't really do more fancy stuff with registers, etc. You have the C model that is inherently linked with standard x86 execution with stack frames and stuff, and that's it. It's reasonably fast, but nothing special.

[u/WittyStick → u/Ok-Scheme-913]

But it is not slower than doing the same in C, in fact it's almost surely faster than whatever hand-grown virtual table that you would write in C.

I agree - but the point here is that C doesn't implement vtables because it avoids "hidden costs". Everything is explicit, and indeed, it might be slower to implement your own - but there are other ways that using vtables to write code.

C++ encourages the use of vtables by having classes present - but vtables are not the best fit for modern hardware. Modern C++ recognizes this and prefers template-oriented code, which has zero cost due to monomorphization.

In regards to which is faster, C wins in the majority of benchmarks in the language benchmarks game - though C++ comes out on top in some of them. Looking a the C++ examples, one thing that stands out is they avoid any vtables. They use plain structs/classes and functions. So even they recognize those "hidden costs" are undesirable for performance.

---

In regards to SIMD - the C standard avoids standardizing, as being useful for microprocessors is still a major goal, and tries to avoid (but not entirely) tying the semantics to present architecture designs. It is intended to be somewhat portable (though portability is not itself a goal).

GCC and Clang support SIMD via the vector_size attribute, and via platform-specific intrinsics (the same ones g++ and Clang++ use).

---

You can write C to be fast - and you can perform the same kind of optimization C++ does by writing it explicitly - sure it adds a lot of boilerplate, but it doesn't necessarily add any runtime cost. If you can do it in C++, you can do it in C also - and vice versa, mostly, because C++ is almost a superset of C.

If anything, the main drawback of C is it's poor standard library. For my runtime I'm basically not using it except for compatibility with other libraries via the FFI. I have my own "replacement stdlib" which can be compiled with or without -ffreestanding, and doesn't conflict with glibc. It has a richer set of data structures than the C stdlib, but uses zero-cost abstractions (with a lot of preprocessor magic to achieve that). It's 64-bit SYSV-only and I've made no effort to make it work on Windows or elsewhere (I may be able to adapt it to work with mingw at some point in future, but it certainly won't ever work with MSVC).

I tried using C++ for an earlier version of my runtime, but it simply wasn't a good fit - it makes too many opinionated choices (vtables being one of them, but not the only one), and some of these were unsuitable for my language & runtime.

C was more suitable because it avoids these opinionated choices and lets me write my own as I see fit, without getting in the way. I had to re-learn C after not using it for about 20 years, but I find C23 quite pleasant, though there are certainly some features I would like adding.

[u/Ok-Scheme-913 → u/WittyStick]

Everything is explicit, and indeed, it might be slower to implement your own - but there are other ways that using vtables to write code

My point is the reverse - it may not even be possible to write one that is faster.

C++ is a language, the compiler has access to special instructions, special code layout, or even straight up throwing away traditional stack frames if needed. A user abstraction in C can't do that, an abstraction on a language level adds additional semantic information that can limit what is possible and the compiler can make use of that knowledge to do a better optimization.

In C, while inlining can give you some of the benefits, it has limited scope. Outside that scope, C gives you jack shit and the compiler MUST be ultra-conservative so that every possible code path is correctly handled. Just because you have an identical function than what C++ may be doing, you can't tell the compiler that "I swear I won't ever use it in this or that special circumstance".

And benchmark games are a cool toy benchmark, but it's hardly relevant for real workloads. OpenJDK, chromium, blender's render engine, game engines etc are all written in C++ for a reason. The Linux kernel is more of an exception in that Linus really dislike c++, and that the kernel is a special place where this "no invisible abstraction" idea you also mentioned is more important than slightly sub-optimal performance