> It says that "our computers are thousands of times faster and more powerful than computers from the 90s and early 2000s" and yet somehow "flexibility and features" destroy all of those advancements.

This is the brain worm.

I agree with Blow and Muratori, et al., re: design patterns which are slow (aggressive OOP), and both are right about the solution (DOD). I agree that GCed languages are slower than minimal runtime non-GCed languages. Blow and Muratori are entirely right about the particulars of these tradeoffs, re: video games, their own software domain. But that's also why it's so frustrating that they don't understand that other software has different tradeoffs.

"Why is this new terminal not so fast?" is a fine question, but the answer is usually something like: Programming is an economic activity with tradeoffs, and, because that's true, perhaps the terminal didn't need to be that fast (by spending the marginal number of hours to make it faster)?

In the past, John Carmack and Michael Abrash did amazing things with the Pentium chip and x86 assembly, because those were the constraints on their problem. But don't forget that they didn't have the kind of constraints software has now. Memory safety and security being one important constraint they didn't really worry about unless that memory unsafety crashed the program. They didn't have distributed systems problems. They didn't have to ship their product to the cloud or the web (although they later did with Quake Live). Games are super interesting and complex, but so are distributed databases.

So -- I'd argue -- it is no less amazing to build the foundational software of the web. Don't kid yourself, these are incredibly hard problems, and it's perfectly okay that such software is not written in C/C++ for all the well known reasons C/C++ has problems in these domains. The reason this argument is such a muddle is because it may not have been reasonable to build some of things we've built without a GC, and that's okay.

From my own experience, I am working on a fuzzy finder in Rust, and let me tell you `fzf`, written in golang, is really hairy competition, because it has loads of features people really want and it doesn't have to worry about half the things I still need to worry about. Is junegunn a "bad" programmer and fzf a "worse" program, because my program is faster in a few arbitrary benchmarks? No, not at all. `fzf` has dozens of features we don't have and is fast enough for its domain, even where the domain expectation is non-GCed tools.