I have a lot of sympathy for that position. The thing that drives me nuts about the codebase I work in now is that it has idioms that involve "promiscuous" memory allocation and then more idioms to fix/cover it up. I'm fine with languages that require completely manual memory allocation (spent most of my career in C). I'm also fine with languages that totally take that burden away. There are tradeoffs either way, but I've seen great code in both of those styles. What I'm not fine with is languages that solve half of the problem and force programmers to learn the brain-dead rules of that half-solution to do their part. STL-heavy C++17 and beyond is, of course, the salient example. I've seen "clever" code in that style, but never great code.
Hah! Yeah, that does seem sometimes like it must have been a deliberate goal, doesn't it? Got a good laugh out of that. The number of cycles wasted by C++ compilers fumbling toward solutions that would have been obvious in a better language (thousands of server-years per day where I work) is a legitimate ecological concern.
I know personally I'd spend a lot less time on HN if C++ compiled quickly enough that I didn't have time to context switch to something else while waiting for it to compile.
