log entry ID: ...a.r.i. 2026-01-26 12:11:45 EET

So. C++. There are those who will be surprised by my aversion to this language. I myself was surprised to find out the truth. After all, it has been used to build great things. I was told that C++ fixes all of the annoying and dangerous problems with C, with no sacrifice to performance. I was told that for serious large scale high-performance software development, like computer games, there was no substitute. In other words, it was supposed to be the best. So, I used it in some personal projects, and I did not hesitate to join a game studio that used it.

As I used it, my experience darkened. Gradually, with the discovery of every new feature. Gradually, I realised that I could not understand C++.

Nobody on my dev team understood it. Not just my dev team. Nobody who uses it understands it, no matter how much experience they have.

You, dear reader. I promise you, that you do not understand it, no matter what you might think. No human can possibly understand it. It is not just unknown, but unknowable.

This is why I give C++ the following moniker.

C++: the Cthulhu of programming languages.

The Thing cannot be described—there is no language for such abysms of shrieking and immemorial lunacy, such eldritch contradictions of all matter, force, and cosmic order.

—H. P. Lovecraft, The Call of Cthulhu

Feature interactions.

Now, this is important to understand, because it is the source of C++’s failure.

Complexity does not scale linearly with each new feature!

Because every feature must interact with every existing feature, you don’t just learn one new thing when you learn a new feature. Rather, you learn N new things, where N is the number of features you already know about. That is actually the best case, because it assumes only pair interactions between features. In reality, for example, a combination of 3 features, ABC, can all interact in a way that cannot be described using only the pair interactions, AB, BC, and AC.

The result is an unknowable mountain of terror and insanity.

The face of perfect insanity: the C++ spec.

It is a thousands-of-pages-long document. Here is a typical page. (This is not actually authoritative. I can’t link to the actual standard because you have to buy it.) To say that it is unreadable would miss the point, and the reason why it is unreadable. It is not unreadable because of its length, or even because of its writing style. One could, in principle, get used to its style, memorise it, or at least become familiar with it. But have you really read something, if you do not understand it? It is in this sense that the spec is unreadable.

Other long books are valuable, and necessary. The knowledge of a typical scientist or medical doctor easily reaches the thousands of pages. The difference is that this knowledge is modular. Especially in mathematics, a book has dependencies downward to simpler mathematics, and builds upon it through small, easy-to-understand steps. The result is a rather short list of true, reliable results, which can then be built upon in the next book up. The book has a central body whose interior is unimportant. Only the dependencies, the assumptions, and the results need to be remembered.

The C++ spec is not like that. Every detail needs to be kept in mind while reading every other detail. The dependencies do not go downward into other books, but everywhere, connecting every part of the standard to every other part. There is no central body that can be read once, then ignored. There is not enough room in the human brain for this task.

Contradictions of reality.

No compiler designer team could possibly implement it according to its spec. It exists and does not exist at the same time.

In spite of everything, it works. It fails and does not fail at the same time.

Other Cthulhus?

Some of you might think I am treating C++ unfairly, and that there are other complex languages out there too. To you, I say: yes. Yes, there are. And they are all cthulhus. But none is quite so bad as C++. Examples are rust and C.

Wait, C?

Yes, even C. C used to be a simple language, but over the decades, the standard has actually become quite complex. There is a reason there are so few C compilers capable of compiling, say, all of the C software in Linux. Basically, just gcc and clang. Sure, there are others, but they’re usually domain-specific, like the compiler that ships with a particular microcontroller.

In spite of this, I will still use C because in spite of its complex standard, there is a sort of gentleman’s agreement among C programmers to only use quite a small subset of C.

Isn’t that what C++ programmers do?

Yes and no.

A language language.

A particular project only uses a small subset of C++. But there is no agreement whatsoever about which small subset to use. Firefox C++ is different from QT C++, which is different from Boost C++, which is different from my old game studio’s C++, which is again different from Google Chrome’s C++. If you’ve only ever written C++ for one company, boy are you ever in for a surprise. You’ll switch to a different company that also uses C++, and then you’ll learn.

You don’t know C++ at all!

This is why C++ isn’t used for most of linux. This lack of agreement over language makes it impossible to agree on some kind of reasonable API between packages.

Do not offer criticism without offering alternatives.

I don’t actually have to do anything here, except point out the way linux actually is right now. This was something that actually surprised me a lot. Because by and large,

Linux does not run on C++.

It uses C. And it gets away with it because package sizes are small and they interface with one another using the C ABI. While not spectacular, it does offer a reasonably simple and straightforward way for packages to establish these interfaces.

For high level code, even high performance code, the world has actually gotten by just fine without C++. For something higher-level, there is the C+python combo, which actually works pretty well, even when performance is necessary.

Finally, if your code is really that high performance, you should start asking yourself whether you’re even running it on the right hardware. These days, all of the real HPC happens on GPUs anyway, and you can only program them with CUDA, OpenCL, GLSL, etc.. And yes, there are python libraries that interface with GLSL etc. for you. No C++ required.

Well, you said C is also pretty bad. Isn’t there a high performance low-level language that actually is simple enough for one human to understand?

Yes. It’s called Hare, and it was written specifically for this purpose. Check it out! :D