The Worst Programming Language of All Time /s

There's a fifty-minute video on YouTube with the proud title «the worst programming language of all time». I wouldn't be surprised if you assumed it was about C++. It really is about C++, and I watched it about half a year ago, well, "watched" is a strong word... I skimmed it at 2x with lots of skipping, whatever an offended junior might have ranted about there, but kind @alyokhinreminded me of it again, and now I've watched it in full. And you know what the most unpleasant part is? If you strip away the offended-junior intonation and leave only the arguments, then about seventy percent of it is true. Not «debatable», not «depends on the context», but literally true, the kind any developer who has spent a couple of years with the language will confirm without a second thought.

The paradox is that this video was made about the language that half the world around us is written in. The browser you're reading this in, the game engine, how could I write an article without games, of the game you played yesterday, the firmware of the hardware it all runs on, and the compiler that built the browser, the engine, and the firmware.

The «why C++ is awful» genre has been scorched to the ground on Habr, and about the Init zoo, overloaded static, vector named incorrectly, std::move that doesn't move, super-slow regex, slow unordered_map you've read it all a dozen times over. The list of these pains itself is old news, and I'll add on my own behalf that all the complaints and examples below are consequences of a single decision, and I'll get to it. Or open the spoilers, they hide the story of why each part of the language turned out the way it did.

Many ways to initialize a variable

Let's start with the most hellish part, with the beginning of any program, that is, with creating a variable. And whereas in other languages this is usually a single operation, in C++ whole books are written about it and studies are conducted, later dragged out onto conferences, as if there weren't enough other problems. Help me out. Did I forget anything?

int f;                    // automatic storage, garbage
static int f_static;      // but in namespace/static scope it's already zero (zero-init at startup)
std::string s;            // default-constructor call
int* p = new int;         // heap, garbage
int e{};                  // 0
int e2 = {};              // 0
int* p = new int{};       // 0
int* q = new int();       // also 0
auto t = T{};             // temporary, value-init
int b(5);
std::string s("hello");
T obj(a1, a2);
auto p = new T(a1, a2);
int x = static_cast<int>(3.5);   // cast, this is also direct-init
int y(int(5));                   // functional notation
int a = 5;
std::string s = "hello";
T obj = other;
f(arg);                   // pass by value, the function PARAMETER is initialized
                          // not a visible variable
f({1, 2, 3});             // same thing
return x;                 // return by value
return {1, 2, 3};         // also, if copy-elision doesn't kick in
throw x;                  // the exception object is initialized
int c{5};                 // direct-list
int d = {5};              // copy-list
std::vector<int> v{1, 2, 3};
std::vector<int> v2 = {1, 2, 3};
std::vector<int> a(10);   // 10 elements, all zeros
std::vector<int> b{10};   // ONE element with value 10
struct Point { int x, y; };
Point p{1, 2};            // you can do this
Point p2 = {1, 2};        // or you can do this
int arr[3] = {1, 2, 3};   // with zeros and without them
int arr2[3] = {};         // all zeros
Point p3{.x = 1, .y = 2}; // designated initializers, C++20
Point p4{1};              // x=1, y=0 (tail value-init)
int& r = x;
const int& cr = 5;        // binding to a temporary + lifetime extension
int&& rr = 10;
constexpr int n = 42;     // must be constant-init
const int m = foo();      // may be either constant or dynamic
constinit int g = bar();  // C++20: guarantees static-init, but does NOT make it const
static int s = compute(); // dynamic-init, with its own Static Init Order Fiasco
struct S {
    int x = 5;            // default member initializer
    int y{10};
    S() : y{2}, x(1) {}   // member initializer list (order by declaration, not by list)
};
auto [a, b] = std::pair{1, 2};   // structured bindings, C++17
for (int v : arr) { }            // range-based for also initializes v

If you count the "behavioral semantics" of initialization, you get about ten of them (= v, (v), {v}, = {v}, {}, = {}, () in new, etc.), and there will be nine semantic categories, and the mapping between them is not one-to-one, and a single {} entry lives simultaneously in value-init, list-init, and aggregate-init depending on the type on the right. On the topic of initialization a separate three-hundred-page book has been written, and that's not a joke, an acquaintance once recommended it to me, it really exists and it really is three hundred pages long, as they say, enjoy.

And each method does something slightly different, I especially like the difference between e and f, where the presence or absence of a pair of curly braces determines whether your variable holds zero or whatever is left over in this chunk of the stack from the previous function call.

struct S {
    int x = 5;     // default member initializer
    int y{10};
};

NSDMI, Non-Static Data Member Initializer, an initializer for a non-static data member right in the class declaration. At the point int x = 5; the object doesn't exist yet and nothing is initialized. This is a default member initializer, that is, just a template that will be used during construction, IF the constructor didn't initialize the member itself in the mem-init-list, that is, it's an «initializer in reserve», not initialization. Formally it's the member's brace-or-equal-initializer.

auto [a, b] = std::pair{1, 2};

And here a hidden anonymous object is initialized (a hidden object or decomposition object , let's call it e), and a and b won't be separate variables, they are binding names to parts of the anonymous object. Initialization is applied to e, not to a/b. A subtlety, but since we're nitpicking, I'll repeat that these aren't quite real variables but fields of a structure, and e itself isn't directly accessible, but physically the storage is roughly like this:

e
+---------+
| first   | <--- a
| second  | <--- b
+---------+

auto e = std::pair{1, 2};
auto& a = e.first;
auto& b = e.second;

int k, e;

int main() {
    auto [a, b] = std::pair{k, e};

    return a + b;
}

leaq    -12(%rbp), %rdi
leaq    k(%rip), %rsi
leaq    e(%rip), %rdx
callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&)

main:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $32, %rsp
        movl    $0, -4(%rbp)
        leaq    -12(%rbp), %rdi  <<<<<
        leaq    k(%rip), %rsi    <<<<<
        leaq    e(%rip), %rdx    <<<<<
        callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&) <<<<<
        leaq    -12(%rbp), %rdi
        callq   tuple_element<0ul, std::pair<int, int>>::type&& std::get<0ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -24(%rbp)
        leaq    -12(%rbp), %rdi
        callq   tuple_element<1ul, std::pair<int, int>>::type&& std::get<1ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -32(%rbp)
        movq    -24(%rbp), %rax
        movl    (%rax), %eax
        movq    -32(%rbp), %rcx
        addl    (%rcx), %eax
        addq    $32, %rsp
        popq    %rbp
        retq

k:
        .long   0

e:
        .long   0

And just as you decide you've figured it out, it turns out that curly braces in one context are aggregate initialization, and in another they're std::initializer_list, and the very same line of code can return a different type depending on the version of the standard you're building against. Not a different result, but a different type. Welcome.

auto i = 1;      // always int
auto j = {1};    // always initializer_list<int> (copy-list-init)
auto k{1};       // C++11: initializer_list<int>;  C++17+: int

Simple things just don't get done simply

The textbook example of complicated simplicity is a random number, and somewhere in Java or Python you just write random.randint(1, 100) and go on coding, but not here. That's too simple to be true.

std::random_device rd;
std::mt19937 gen(rd());                          // and what is mt19937?
std::uniform_int_distribution<int> dist(1, 100); // and why separately?
int value = dist(gen);                           // finally

The code isn't exactly unreadable, but you have to look it up on cppreference every other time you actually need it. Then I go googling what this mt19937 is, it's the Mersenne Twister, live with that knowledge now, and yes, you now have to know the name of the pseudo-random number generator just to roll a die.

Casting problems

Casting is a whole separate song, and where in Java you write the value in parentheses and that's it, in C++ there's a whole set of these casts, for every taste and color. static_cast, dynamic_cast, reinterpret_cast, const_cast, bit_cast, and each for its own case, and each has to be typed out in full by hand, and there's also a hidden rvalue_cast, but more on that below.

double d = 3.9;
int i = static_cast<int>(d);        // 3, fractional part discarded

Base* b = new Derived;
auto* der = static_cast<Derived*>(b); // downcast WITHOUT a check
                                      // you vouch that it's a Derived

Base* b = get_something();
if (Derived* d = dynamic_cast<Derived*>(b)) {
    d->derived_only();              // we get here only if it's really a Derived
}                                   // otherwise d == nullptr

int x = 42;
std::uintptr_t addr = reinterpret_cast<std::uintptr_t>(&x);  // address as a number

void legacy_api(char* s);           // doesn't touch the string, but forgot const

const std::string str = "hello";
legacy_api(const_cast<char*>(str.c_str()));   // ok, since the api really doesn't modify

float f = 1.0f;
auto bits = std::bit_cast<std::uint32_t>(f);  // 0x3F800000, no UB

// how it was done before C++20:
std::uint32_t old;
std::memcpy(&old, &f, sizeof f);              // same thing, but by hand

int i = (int)d;                     // compiles, looks familiar

Newcomers get so tired of this that they set up a short alias for themselves, and this is considered bad practice, because now your code is written in your own personal dialect of C++ that nobody but you knows.

// antipattern: "I'm tired of writing static_cast"
template <class T, class U>
constexpr T sc(U&& u) { return static_cast<T>(std::forward<U>(u)); }

int i = sc<int>(3.9);               // short, yes, correct? no

// or even worse:
#define CAST(T, x) static_cast<T>(x)

This is a real trap, and often correct C++ looks incorrect, because the short and beautiful solution almost always turns out to be buggy and incorrect, while the correct one looks as if you needlessly complicated your team's life. The intuition for «what good code should look like» takes years to develop, and until it's developed, you live with the feeling that you're doing something wrong. Spoiler: you really are doing something wrong, the language is just like that.

Keywords that lie

In a normal world a keyword describes what it does, but in C++ that became an optional add-on. Remember static.

And do you remember how many meanings it has? Making a variable that lives between function calls, that's one. Making a variable or method shared across all instances of a class, that's two. The third meaning, when static before a function in a .cpp file makes it invisible outside that file, that is, it's private, but they called it static. Why not internal, not private, not file_local? Because historically it just ended up that way, which is the answer to about half the questions in this article.

void counter() {
    static int calls = 0;   // initialized ONCE, on the first entry
    int local = 0;          // ordinary local, anew each call
    ++calls;
    ++local;
    std::cout << "static: " << calls << ", local: " << local << '\n';
}

And there's a behavior of static that came after C++11, now your staticalso means a light mutex guarded. Did you know about this?

Logger& logger() {
    static Logger instance;   // one line
    return instance;
}

Logger& logger() {
    // FAST path: low byte of guard != 0 → already initialized
    if ((reinterpret_cast<volatile char&>(__guard_for_instance)) == 0) {

        // SLOW path: we get here only on the first time and under synchronization
        if (__cxa_guard_acquire(&__guard_for_instance)) {
            // acquire returned 1 → this exact thread is obligated to initialize.
            // The other threads are now SLEEPING inside __cxa_guard_acquire.
            try {
                ::new (&__instance_storage) Logger();          // constructor call
                __cxa_guard_release(&__guard_for_instance);    // set the flag, wake the sleepers
                __cxa_atexit(&destroy_logger, ...);            // register destruction
            } catch (...) {
                __cxa_guard_abort(&__guard_for_instance);
                throw;
            }
        }
        // the threads that lost the race left acquire only after release
    }
    return reinterpret_cast<Logger&>(__instance_storage);
}

inline once it asked the compiler to inline a function, but today the compiler is smart and inlines on its own when it sees fit, and inline now solves linking problems and the One Definition Rule. And inline on a function and inline on a variable do semantically opposite things, and on a function it's permission to duplicate code, while on a variable it's a prohibition on duplicating data.

// math.h
inline int square(int x) { return x * x; }

// a.cpp
#include "math.h"
int use_a() { return square(3); }

// b.cpp
#include "math.h"
int use_b() { return square(4); }

// counter.h
inline int g_calls = 0;   // exactly one instance for the whole program

// a.cpp
#include "counter.h"
void hit_a() { ++g_calls; }

// b.cpp
#include "counter.h"
void hit_b() { ++g_calls; }

// config.h
struct Config {
    static inline int instances = 0;          // one counter for all objects, right in the .h
};

inline constexpr double kPi = 3.14159265358979;  // header-only constant, one object

const, which is supposedly about immutability, can be written on either side of the type, and both spellings mean exactly the same thing, just so you don't relax. And also mutable const is sometimes valid code. And also constness can be stripped with a cast, and that's bad practice, but physically it can be done.

To figure out what const refers to in a pointer declaration, to the value or to the pointer itself, there's an official rule «read right to left». Let me remind you that most people read left to right.

const int a = 5;   // "west const"
int const b = 5;   // "east const" exactly the same thing, both are constants

const int* p = &a; // pointer to const int
int const* q = &a; // and this is the same thing

struct Cache {
    mutable int hits = 0;   // can be changed even on a const object
    int value = 0;
};

const Cache c;
c.hits++;       // OK, mutable
// c.value++;   // error, an ordinary member of a const object

struct S {
    mutable const int* p = nullptr;  // VALID
};

struct Bad {
    mutable const int x = 5;  // INVALID, mutable can't be on a const member
};

// Case 1: the object is REALLY not const, ok
int x = 5;
const int& cref = x;
const_cast<int&>(cref) = 10;   // legal, x really did change, x == 10

// Case 2: the object is REALLY const, Undefined Behavior
const int y = 5;
const_cast<int&>(y) = 10;      // compiles, but this is UB
                               // y may stay 5, crash, or anything

int x = 0, y = 0;

const int* p1 = &x;        // p1: pointer to const int
int* const p2 = &x;        // p2: const pointer to int
const int* const p3 = &x;  // p3: const pointer to const int

*p1 = 5;   // error: the value is const
p1 = &y;   // ok: the pointer can be redirected

*p2 = 5;   // ok: the value can be changed
p2 = &y;   // error: the pointer is const

*p3 = 5;   // error
p3 = &y;   // error

const int* p;   // pointer to const int, change the pointer, not the value
int* const p;   // const pointer to int, change the value, not the pointer

The integer type zoo

How many integer types are there in C++? About fifty (if you count the fixed-width aliases too). And the size of not all of them is fixed, but depends on the compiler and platform.

bool                    // yes, bool — is also an integral type

char                    // a SEPARATE type
signed char             // a SEPARATE type
unsigned char           // a SEPARATE type, these are three different types, not two

char8_t                 // C++20
char16_t                // C++11
char32_t                // C++11
wchar_t

short
unsigned short
int
unsigned int
long
unsigned long
long long               // C++11
unsigned long long      // C++11

short, short int, signed short, signed short int          // 4 spellings → 1 type
int, signed, signed int                                   // 3 spellings → 1 type
long, long int, signed long, signed long int              // 4 → 1
long long, long long int, signed long long, signed long long int  // 4 → 1
unsigned, unsigned int                                    // 2 → 1

int8_t   int16_t   int32_t   int64_t        // exact width (optional)
uint8_t  uint16_t  uint32_t  uint64_t       // 8 of them

int_least8_t  ... int_least64_t             // minimum width
uint_least8_t ... uint_least64_t            // 8 of them (mandatory)

int_fast8_t   ... int_fast64_t              // "fast" width
uint_fast8_t  ... uint_fast64_t             // 8 of them

intmax_t  uintmax_t                          // the widest
intptr_t  uintptr_t                          // pointer-sized (optional)

std::size_t        // <cstddef>
std::ptrdiff_t     // <cstddef>
std::sig_atomic_t  // <csignal>
std::wint_t        // <cwchar>
std::streamsize, std::streamoff   // <ios>

int isn't «32 bits», it's «at least 16 bits, but maybe 32», and only the chain short <= int <= long <= long long is guaranteed. On 64-bit Linux long is 64 bits, and on 64-bit Windows long is still 32 bits, because of backward compatibility (remember this phrase). To get a predictable 64-bit type, there's int64_t, and I honestly don't understand why it has the _t suffix, we're not in the nineties anymore, but it can no longer be changed, more on that under the spoiler.

The character types are separately wonderful, there are seven of them, and sooner or later you'll run into the question of why a character can even be signed and unsigned, like a number, how char differs from signed char and unsigned char (and these are three different types, not two), what wchar_t is, and what the difference is between std::string and std::wstring, and why because of it your encoding will break out of nowhere, but about that some other time.

The non-standard library

If I wanted to confuse a newcomer as much as possible, I'd name things exactly the way they're named in the STL. The most-used container is called vector and it's our dynamic array, but a vector in the ordinary sense is a quantity with a direction, and Alexander Stepanov himself, the author of the STL, acknowledged that the name was a mistake.

If you wanted a hash table, you'll have to take std::map, but that's a balanced tree with logarithmic lookup. And a real hash table is std::unordered_map, which, spoiler, is also best not to use, because it's slow, and it's not that «the implementation is lazy», it's baked into the standard itself. The guarantees that std::unordered_map is obligated to provide leave the libstdc++/libc++ developer no choice but to make it slow.

std::map<std::string, int> ordered;
ordered["banana"] = 1;
ordered["apple"]  = 2;
ordered["cherry"] = 3;

for (auto& [k, v] : ordered)
    std::cout << k << ' ';       // ALWAYS: apple banana cherry, in ascending key order

std::unordered_map<std::string, int> hashed;
hashed["banana"] = 1;
hashed["apple"]  = 2;
hashed["cherry"] = 3;

for (auto& [k, v] : hashed)
    std::cout << k << ' ';       // arbitrary order, depends on the hash and buckets

std::unordered_map<std::string, int> m;
m.insert({"key", 1});
m.insert({"key", 2});            // did NOT overwrite, but returned {iterator, false}
std::cout << m["key"];           // 1, not 2

m.insert_or_assign("key", 2);    // after C++17 this one will overwrite
std::cout << m["key"];           // 2
m["key"] = 2;                    // or just like this

The standard effectively requires separate chaining (separate storage) with nodes and unordered_map is obligated to guarantee stability of references and pointers to elements after insert/erase (except the removed one), so that a pointer to an element stays valid even when the container rehashes.

And this is only possible if each element is separately allocated on the heap (std::pair<const Key, Value> plus a pointer to the next), and a bucket is made as a linked list of such elements. That is, per the standard it's not a «hash table in an array», but an «array of pointers to lists scattered across the heap». Or another gag with the same thing:

std::unordered_map<std::string, int> m;
if (m["key"] == 0) { }    // if the key was NOT there, it just got inserted
                          // with the default value 0. The "does the key exist" check created it.

operator[] on a missing key silently inserts a default value, so you have to check for presence via find/contains, not via []. A trifle, of course, but newcomers step on this rake regularly.

And also containers have empty(), which looks like «clear it», but it's our question «is the container empty?». In human terms it would be is_empty(), but no, whereas there'sremove(), which doesn't remove anything at all, but instead shifts the elements to the end and returns an iterator, and you'll be removing separately (hello, erase-remove idiom). And there's also std::stoi, std::stol, std::stoll, std::stof, std::stod, std::stold, and you're just supposed to know what these are. You do know, right?

And don't forget about ...value

And to make things really nice for you, recall that there's lvalue, rvalue, glvalue, prvalue, and xvalue. Recall them?

And there are also situations where std::move makes a copy, and that sometimes you need not std::move, but std::move_if_noexcept. Since we're on the subject of moving, std::move has historically had an incorrect name, and it doesn't move anything, but just casts a value to an rvalue reference, allowing it to bind to a move constructor. It should have been called rvalue_cast, ah damn... then we'd have one more cast.

And also the standard library has a second std::move, which honestly does move elements, so don't confuse the one that moves with the one that doesn't move. And someone even showed me a 70-page PDF on how and when to correctly use both std::move, too bad I didn't remember the title.

And I'm not even nitpicking at the names of idioms yet. Remember RAII from the article about C++101? It stands for Resource Acquisition Is Initialization, that is, acquiring a resource is its initialization, but it describes the exact opposite moment, and in the idiom the main thing isn't the acquisition of a resource, but its automatic release in the destructor on exit from the scope. That is, it would be CADR (Constructor Acquires, Destructor Releases, «the constructor acquires, the destructor releases»), not RAII (creates a resource in the constructor).

void process() {
    FileHandle file("data.txt");   // opened

    if (nothing_to_do())
        return;                    // early exit — the file is closed automatically

    might_throw();                 // threw an exception — the file is STILL closed
}                                  // ordinary end of scope — the destructor closed the file

Or another example, CRTP - did you read into the name of the idiom? CRTP is the Curiously Recurring Template Pattern, «a curiously recurring pattern», and the name describes not what the pattern does, but the fact that the person who came up with it ran into it several times in projects and was surprised by this coincidence, and then named the pattern that way.

Modern C++

Heard that you should learn modern C++? But when you google what modern C++ is, you land on books from umpteen years ago.

Effective Modern C++ by Scott Meyers (2014), and right in the subtitle «42 Specific Ways to Improve Your Use of C++11 and C++14»

Modern C++ Design: Generic Programming and Design Patterns Applied

The Modern C++ Challenge

Modern C++: Efficient and Scalable Application Development

C++11 was the first «modern» one, it brought smart pointers, lambdas, and move semantics. Then came 14, 17, 20, 23, and each declared itself the newest and now surely, definitely «modern». And already the best-selling textbook on modern C++, «Effective Modern C++», is no longer modern, and in places not even particularly effective. Meanwhile the industry lives somewhere around C++17, because nobody wants to rewrite millions of lines of working code to be «more modern than modern», because it's scary.

The upshot is that you're forced to know all versions of the standard at once (and they differ, believe me), because the old code at work is written in one dialect, the new one in another, the textbook has a third, the YouTube tutorial has a fourth, and none of them are modern.

Errors that don't fit on a monitor

When you finally compile something, you're greeted by error messages. C++ can dump a thousand lines of unreadable garbage over a single misplaced squiggle, with the real cause buried somewhere in the middle, but your brain can no longer perceive it, because half the text is the guts of the standard library leaked to the outside.

A template instantiation error is unconventional Chinese made of angle brackets, taking up so much horizontal space that it no longer fits on a 4K monitor. I seriously started to understand the point of ultrawide monitors precisely while looking at these errors, and over time I also started turning off line wrapping, because with wrapping it only got worse. No wonder many C++ developers have ultrawide monitors, glasses, and a bad neck.

Zero-maybe abstractions

For the last twenty years or so C++ has been selling itself as a language of zero-cost abstractions, but any abstractions are no longer free, and std::unique_ptr is slower than a raw pointer: it has a non-trivial destructor, and such a type can't be passed in a register per the Itanium ABI. Only through the stack, whereas a bare pointer would fly into a register.

And this isn't only about smart pointers, but about any type with a non-trivial destructor: shared_ptr, string, vector are moved by value through memory for the same reason. Move semantics aren't free, the problem is in the destructor, when non-destructive move is used, so the object you moved from still runs its destructor, and equivalent hand-written code would be faster.

The regular expressions in the standard library are considered one of the worst implementations in existence, in places tens and hundreds of times slower than the alternatives, and just including <regex> alone adds a good second of compilation to each translation unit if you're lucky.

unordered_map is slow because it's slow and cache-unfriendly, and if you need speed, you drag in flat_hash_map from Google's Abseil or F14 from Facebook's Folly. Notice the pattern? A ton of things in C++ could become significantly faster, but won't. Because it would break ABI compatibility, and here we come to the main point.

Compatibility at the cost of everything

All the grievances above, from crooked names to slow containers, from the static zoo to invisible copies, converge on a single point. People think C++ is a language that puts performance first, but in reality it puts backward compatibility first. Screw performance, screw development ergonomics, screw the developer experience, screw everything in general.

It's precisely the commitment to compatibility that turned the language into a monster, when you can't rename vector because a billion lines of code would break, and you can't speed up unordered_map because the ABI would change, and you absolutely cannot make destructive move, because the moment was missed some ten years ago, and you can't break what exists. Every ugliness of the language is a stone flower of a wrong decision from the past that can't be thrown out, because something already stands on it: someone's lib, an engine, a game, or a pipeline.

But the very property C++ is scolded for is the very property thanks to which half the world is written in it. Compatibility is both the disease and the reason for survival, because the code you wrote twenty years ago will, with some dancing and a tambourine, still compile. A library abandoned in 2008 still links, and for the game industry, where the cost of rewriting is measured in person-decades, this isn't a bug, it's a load-bearing wall.

But what about Rust?

People here asked me in the comments to weigh in on Rust. I hope we can do without religious wars, it's just different.

Rust is an order of magnitude better by design. A standard compiler, a standard build, a standard package manager, no header files, the best error messages I've seen, sane defaults, the absence of implicit conversions, proper UTF-8, sum types, and memory safety at compile time. Many problems that in C++ aren't solved and likely won't be solved in the next ten years, in Rust were already solved yesterday.

But «better by design» doesn't equal «you should take it». Game development is fast iteration, creative chaos, and «let's try it this way», and Rust doesn't give you that, and honestly - C++ doesn't give you that anymore either, however new and modern it may be. That's why games moved to scripts, DSLs, and declarative programming.

And Rust is fundamentally about correctness and discipline, and this conflict is fundamental, which led to there being a growing pile of games that started on Rust and moved off it. Plus the ecosystem, however you twist and turn, CUDA, engines, tooling, gazillions of lines of ready-made code, all of it is C++, and will be for a very long time.

The [W/B]orst programming language of all time?

C++ is a terrible language. Verbose where it needn't be, and silent also where it needn't be. With a type zoo, lying keywords, invisible copies, unreadable errors, and build hell.

To write in it correctly you need an encyclopedic memory for exceptions, and once you've learned the exceptions, separately for the exceptions to the exceptions. But C++ is more alive than all the living, and will trade away another several decades, because it has monstrous inertia and it's one of the few that chose compatibility at any cost, probably at the cost of everything. And this choice made it simultaneously unbearable and irreplaceable. Half the world runs on it, and will run on it for a long time, whether I like it or not.

I write in this terrible language, romanticizing its complexity and proving to myself that I'm smart. And I'll keep writing in it, because in my field it's so far the only one that delivers the necessary performance, having become a load-bearing wall. And replacing this load-bearing wall in an "inhabited" and "living" house isn't just «rewrite a couple of rooms in a trendy language», it's tearing down the whole damn house and building a new one in its place, having lived a couple of years out on the street in a little shed.

So yes, the language is terrible, so go ahead and open your terrible IDE already, and keep writing in the worst programming language.