I still point to wide adoption of boost:: as reason why C++ should never be used. If 4 pages of a single error message isn't enough to convince someone, nothing will.
Those 4 pages of errors are useful as hell though. Some languages are better at giving you just the important bits (Rust) but a lot of languages suffer from "simple errors obscuring complex problems" syndrome.
C++ compile errors, particularly overloading and template errors are normally just some fairly tiny succinct errors (could not find a suitable method/type/operator) with a whole bunch of debug information attached that tells you exactly what the compiler tried and how it came to the conclusion that it could not proceed.
I can take that information and work out exactly why my code is failing to compile 99% of the time but it's rather often in other languages that I get a succinct 1-3 line error that provides little to no context beyond where in the code it is. That leaves me to dig through stack overflow in the hopes that I can find someone with the same error and a similar code layout such that I can determine what is inducing the error.
Don't get me wrong, C++ has a whole lot of issues which justify why things like Rust should be preferred wherever possible but the errors aren't nearly as bad as people make them out to be. I'm much more concerned with the cancer that are C & C++ arithmetic rules(https://twitter.com/hackingcpp/status/1492242039110524935). Likewise for the numerous ways you can accidentally introduce undefined behavior when interacting with non "new C++" code (and even sometimes then as well).
Honestly I have to disagree. There is nothing particularly special about what Super Template Tetris(STT) is doing.
At its core, template metaprogramming is just functional programming at compile time. STT is just a template and a runtime function which do the following:
1, take an input via compile time flag (the `-D DIRECTION`)
2. take a type input from an included header file containing the current state (`#include "current_game.h"`)
3. via functional programming, compute the results of a single step of the game.
4. specialise a single function using the results of step 3. this function prints the computed result to the screen and the computed game state to a file (`./current_game.h`).
5. gcc/clang exits. compilation is complete.
6. call the compiled binary.
7. the binary runs the specialised function and prints the outputs.
Sure it's fucky and you shouldn't do that in production but what sane individual is writing a piece of code that at runtime (after compiling) seeks out one of its own source files and modifies that file?
To prevent this from being possible you'd have to remove runtime file IO from the language. The other potential solutions wouldn't work:
1. Remove templates entirely: Still would be possible using https://github.com/Hirrolot/metalang99 which solely uses the preprocessor. Given that the pre-processor is literally just term substitution(a glorified copy/paste engine), if you removed that as well, you'd have to accept no form of metaprogramming at all.
2. Remove the ability to #include other files: Could still be done by doing everything inline. `#include` is just copy-paste anyways so it's more an abstraction than anything else to the compiler and preprocessor, it's basically the same as if all the code was pasted into the same file.
That leaves you with removing file IO. Without IO a programming language is basically useless, particularly as a systems programming language.
Most production C++ codebases are very wary of using much boost. Two of the four places I worked at (wrote C++ at all of them), the use of boost was very minimal and only when absolutely needed. The first place where this was the rule, the only boost usage was boost.asio, at my current place boost.circular_buffer is the only thing we use.
who cares about 4 pages of error message ? it's one double-click away in my IDE to go to the line in my code that has the issue whether it's one line or 500. this is an absolute non-problem. and if you don't have an IDE just ctrl-f the magic words "required from here" (with gcc) or "requested here": the last one will point to the place in your code where the issue comes from
