[ajross]

Conversely, it's be my experience that the most of C++'s most ardent adherents haven't "seriously used" other environments. Specifically, they tend to have a very poor grasp of both dynamically typed languages and functional programming. While they might "know" tools like Python, they don't think in these languages well and tend to write very clumsy code.

For myself, once I got to a point where I could "think well" using syntax at both a high level of abstraction and write solid C code at the system call level I found that the space of "appropriate" problems for C++ had shrunk to almost nothing. By itself, if it's the only language you're ever going to learn, C++ is not a bad choice. But in the modern world of polyglot development on CPUs too fast to measure, it's almost never the best one.

[ramchip]

I found that the space of "appropriate" problems for C++ had shrunk to almost nothing. As a fairly low-level programmer (data acquisition, signal/image processing), this isn't quite my experience. I've found that a mix of simple C-style code for the layers that directly interact with the material, with higher-level layers such as the GUI implemented in the usual C++, makes for a very decent mix, and certainly a better one than plain C.

I could also keep the systems stuff in C functions and use an FFI to call them, but I've never found a language that enabled me to write GUIs more easily than with plain old C++ and Qt. Java (or Java from Clojure) is slow and ugly as sin, and most other languages either use bindings to C/C++ libraries or have incomplete, mostly unsupported kits. C# and family is perhaps an exception, but not very portable.