I think you are right - as far as 'the' language is concerned. The complexity (and the slowness) of a C++ compiler now is mostly due to the complexity - and the slowness - of the built-in interpreter of the template meta-language. There are other, saner languages, such as Common Lisp, where the meta-language is indistinguishable from the language itself, which, in addition to its greater simplicity, greatly contributes to the reasonable compile times. In the C/C++ land, it might have been possible to use a similar approach instead of introducing a separate macro/template syntax, a good example being the approach taken in the design of ASP (active server pages), PHP, and the like.
You may want to take a quick gander at the profile of whom you're replying to. :)
>... itching to give Rust a ride once it stabilizes just a bit more ...
Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.
What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.
Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is.
[0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_...
[1] https://users.rust-lang.org/t/rust-version-support-in-librar...
[2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957
[3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155
There's every reason to think that evolving human systems should use similar masks on features of a technology to make it more suitable for a particular domain and serve as a signal to drive the base evolution.
The restricted C subset used for safety critical systems I think is a good example of this -- the restriction allows for usage in a domain where the full set of features is a disadvantage.
What most people nowadays recommend programming in is actually not C++, and actually C++ + all compiler warnings, which is in itself an extension/evolution/restriction of the underlying language. So it's not so far out to go from there to externalizing more rules around valid programs.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
As a day-to-day C++ practitioner I like it.
...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out.
My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++).
And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list).
EDIT: Removed the sir.