Writing Efficient C++ Code (2013)

And, if you can do that in a week (even without good error messages), I'd be very impressed.

To be clear, I can't even promise just the parser in a week. But I do expect a language specialist would already have a C parser. Anyway, from the look of it the parsing bit is the least of my worries…

I don't think defer is as good an answer to resource management as RAII.

It's not indeed. The hope here is that arenas make destructors much less necessary, to the point where defer can take up most of the slack. It is most likely a bit more error prone than smart pointers assisted RAII, but it's also quite a bit faster. Also, if you're doing so many complicated allocations to begin with, perhaps a full blown garbage collector is the better choice?

At this point you realise that just adding generics to C and doing it well ends up with a language that is more complex to implement than C++, doing it badly ends up being 80+% of the complexity of C++.

Actually the goal isn't to do it well, it's to do it well enough. Mostly I just want my generic collections, I use them all the time. What I rarely ever do is write template code. Like, it happens once every other year, and half the time it's to implement my own hash table or similar.

What I get from there is that generics in a systems language is mostly foundational stuff: we don't need much of it, we just use it everywhere. And since we have a language specialist on site (that's a core premise), we can cheat. At the extreme we could even take Odin's approach: no generics at all beyond the built in types… and we add new ones as we need them.

Kind of a cop out, not to mention I'm moving the goalpost 6 feet underground.

Having implemented parametric polymorphism myself for a little scripting language as a complete compiler beginner (to give you an idea I couldn't write the bytecode compiler in C++ at all, I had to switch to OCaml), I expected adding them even to something like C would be manageable. Oops.

Some of the issues I was aware of. Linking for instance I was thinking of sidestepping by simply not using any generics across link boundaries. But that's probably too restrictive. What I think we can get away with is no generics across library boundaries. Like Rust crates: if we ship an .so or .dll with a header file, then its API sticks to pure C, no generics at all.

The other issues… I don't know. They kinda dash any hope of a simple yet generally useful generics system.

Overall, I'm growing increasingly frustrated with C++. As years go by I find myself using it less and less. In the domains I touch at least it would seem plain C is good enough for much more than I thought when I started out as an FP weenie. But if I'm being honest C too is incredibly frustrating. Way, way, way too much UB.

At this point I want to move to Zig or Rust… except C is still more portable. So I muse about making some language that compiles to C. And I don't mean just using C as a backend for whatever I come up with, but designing something around the limitations of such a backend. Something close enough to C to make the mapping easy, or even trivial, but with a couple more features, and much fewer foot guns.

But it looks like those generics are going to be a serious problem.