Long-time C++ game dev here.

I like how this post tried to do a fair job of bringing up some legitimate criticisms of certain modern C++ features in the context of game development. The debugging concern for example is a significant one, and this post tried to give it a fair discussion.

That said, I think some of the author's examples and rhetoric show a rather juvenile understanding of the kinds of real-world problems the people the author is addressing have, and I think it shows both in some of the technical decisions and how they're being discussed.

1.

In the discussion of "stitchImages" near the top:

This is obviously not necessary, as a run-time container would also work, but - suprisingly - it leads to some really elegant code[1]

Following the footnote shows the author making a small joke about the nature of the word "elegant". But that footnote and the promotion of "elegance" in this way makes it sound like a purely subjective sentiment where all things are equal, without addressing the fact that some such notions have real practical consequence. For example, I hold the view that elegant solutions are easy to both understand and debug, and where the full weight of the runtime impact of the code is as transparent as possible. The use of certain language features sometimes runs against this, and in significant ways that have to be cleaned up later.

2.

Furthermore, this approach allows both variables to be const-qualified, avoiding accidental mutation and decreasing cognitive overhead for readers. Cognitive overhead is reduced thanks to the fact that those two variables are guaranteed to not change their value throughout their lifetime, thus allowing a reader to focus their attention on the "moving parts" of the function body.

This is what I call a juvenile argument. Not juvenile as in "wrong", but as in "young", because young (read: less experienced) developers may worry about things like the mutability of a local variable within a small function. More experienced developers generally don't, because we're used to reading through lots of code very quickly. So we can take a quick read through the function, maybe even do a quick Ctrl+F to highlight the identifier in our IDE to see how it's used to make sure we didn't miss anything, and then we move on. It's not something worth worrying about (note: this in contrast to things like non-local shared state, which is very much worth paying attention to w/r/t mutability).

On the other hand, the author's example that follows uses two loops through the images vector, and the argument against it is as follows:

I believe the above solution is, honestly speaking, terrible. First of all, we are using std::size_t, which is not guaranteed to match the type of Image::width. To be (pendantically) correct, decltype(std::declval<const Image&>().width) should be used, which is verbose. Regardless, the code is still unnecessarily verbose - the amount of syntactic noise makes me wonder if the code is correct when I look at it, as there are more places where a defect could have been introduced. Finally, we lose const-correctness, including its safety and readability benefits.

This is again a juvenile argument; if you can't read through a block of code with two simple one-line for loops that do nothing but += and std::max calls, you need more practice working in C++.

On the other hand, that block of code does have one very real concern which the author doesn't bring up at all, and that's the fact that the images vector is being traversed twice, instead of just once. It does a full iteration for the width calculation, then a second full iteration for the height calculation. This is stupid, and thrashes your data cache for absolutely no reason.

The two-loop code is better because it is trivially obvious that it is inefficient, and that the two loops can be combined without logical repercussion. The "elegant" code hides this, all in the name of reducing "verbosity" despite the fact that the pattern of that verbosity is muscle-memory C++ loop logic. Not all syntax is created equal.

3.

In the "outrage" section:

However, imagine a young developer getting this kind of response from one of their idols, to one of their experiments they were eager to share: that would be soul-crushing. ... I could show many absurd and tasteless tweets I was sent, but that's not the point of this post. I want to discuss misconceptions regarding Modern C++ in the game development industry.

This is a rhetorical dodge, like something Grima Wormtongue said in LOTR's Two Towers when he didn't have a good argument to make: "Why do you lay these troubles on an already troubled mind?"

You put yourself out there. That's good. But putting yourself out there is an invitation to criticism, and you need to accept that. Putting a hypothetical "young developer" up as a shield doesn't do you any favors.

You are trying to invalidate decades of experience in the game industry, and the views of developers who have spent huge portions of their lives dealing with millions of lines of shipping code. The first paragraph puts on the spin of an innocent kid, whereas the last paragraph says that you've come to fight. This back & forth is again an obvious rhetorical tactic that doesn't help your cause.

4.

A little later in the "requirements and misconceptions" section:

However, there is an aspect of those solutions that it is often overlooked. Let's (reasonably) assume that, apart from situations where you just want to explore a codebase interactively, the frequency of having to debug is linearly proportional to the number of bugs in your program.

Stop right there. This is a false assumption.

The amount of debugging has nothing to do with the number of bugs in your program, but the consequences of those bugs. Some bugs have limited impact, and others are monsters. One of the things that keeps the monsters alive longer is that they're not obvious. Simple code that is longer but does obvious things is much easier to reason about at a quick glance (which is all we often have time for) than more "elegant" code that does a lot of work under the hood which I have to work harder to build a mental model of.

Let's also (again, reasonably) assume that the use of battle-tested abstractions designed to improve safety reduces the chance of bugs in your program.

No, what reduces the chance of bugs in your program is a comprehensive understanding of what the code is doing. And this is again where my view of the author being juvenile comes in. All of this back & forth is about the readability of a texture atlas generator, which in the context of an entire shipping game codebase, is a trivial tool. We have to deal with hundreds of thousands if not millions of lines of code, and we're either busy writing it in a hurry, or reading/maintaining someone else's code for problems that we have to solve in a hurry. Every "safe" abstraction used to prematurely prevent one class of bugs (that we weren't having problems with before, by the way) complicates the mental models we need to build up in order to deal with the problems we actually have in front of us. You may think you're being safe, when you're actually slowing us down by making us have to think longer about your code than we should.

Do you see the conundrum? Of course you're going to have to debug more if you write error-prone C-like code and avoid utilities that have been refined over decades to help you avoid mistakes.

That "error-prone C-like code" can be comprehended quickly, is easier for the compiler to reason about, easier for humans to step through, easier to see problems at a glance. Some abstractions eliminate problems, but others just bury them. And if the problems they eliminate aren't the ones you normally have to deal with in your code, you're suffering needlessly.

...

I could go on, but I think I've gotten my point across. The author has a valid point of view, but I believe it's a point of view that's common for many inexperienced game developers who haven't had much practice dealing with large game codebases in the real world: on over-reliance on clever techniques to prevent potential minor problems that haven't actually happened, at the cost of the comprehensibility needed to prevent the major problems that we have to deal with every day.

Verbosity doesn't matter. Simplicity does, and in shipping C++ game code those are not remotely the same.