There seems to be some agreement that C++ overdid it. Both Go and Rust have more limited generic systems.
error handling needing to be designed in
I'm not expressing an opinion on return values vs exceptions. But some kind of standard is needed or library error reporting is terrible.
For example, if you look at what type traits are used for, it's essentially making up for the fact that C++ lacked semantics for compile-time checks of generic arguments, forcing anyone that needed to care about that to implement their own (often simple, special case) constraint solvers. Meanwhile, typeclasses in other languages wrote a generic constraint solver (ironic) and support the semantics to express those constraints on generic types, obviating the need for any kind of complex compile-time template logic hackery. Essentially the lack of semantics for a simple concept (yet difficult implementation behind it) forced the implementation of a simple extension to the same syntax that enabled really complex macro programming using the same templating engines.
It's no surprise that metaprogramming in C++ is exceptionally weird; it supports neither proper macros or generic programming, yet half-implemented both through templates to solve the lack of either.
Fast builds would be high on the list of my own "dream language" features. Long developer iteration times are poison.
That should have been buried decades ago and replaced by modules.
They're slowly layering in those ergonomics, which will eventually be nice, though there'll always be a big pile of legacy.
I'd love to know if you write lots of code and/or have to maintain other people's hugely templated code. I find if you have to do lots of the second you quickly stop writing it.
Vehemently disagree on both