I'm a game developer using C++ every day at work. It's the standard in our industry (at least for AAA games) and probably will be for at least another decade.
I used to choose C for pet projects (when I cared about performance) but I've been learning Rust for ~3 months now. I think I'll replace my usage of C by Rust from here on as much as I can.
I also had a brief affair writing Go but it didn't resonate nearly as well with my background as Rust does.
And yet, I'm laughing. As you know, that was what we called the C preprocessor thing back in the mid 80s (as discussed in Uni - I never used it until about 1990)
I went to Java/.NET lands and respective languages.
Since 2006, I only had one project where using C++ really mattered. A mix of Assembly and C++ was used for image codecs, which were just 5% of the whole application done in WPF.
On personal projects, I went back to it for portable code across Android and Windows Store, but now with Xamarin being part of Microsoft, I am using it for newer projects.
Java/C#, though the complexity is now matching C++, especially with all the new fashionable functional "features" most large code bases are a huge mishmash of styles and complexity that is making me wish for sensible C++ developers again.
The problem with Java isn't so much the language. It's the ecosystem and the community. The ecosystem is very rich, so there are many ways of doing pretty much anything, which means it's easy to get lost in the complexity. And the community is fad-prone. Patterns! Injection! Annotations! Something else (for now)!
Haskell has syntax that is as problematic as this one, and a huge number of extension combinations that nobody can be sure not to be problematic.
I'm running into it as much as I can too, but it does look like a language we should replace with something simpler once we get an specification that works.
The C++ usage (T x{{}}) is problematic because its interpretation is so obscure as to flirt with ambiguity and lead to program-breaking changes in compilers as their semantic analyzers improved. The Haskell line you cite isn't ambiguous at all.
About obscurity, how many GHC extensions were required to make it accept this code? (Is GADT enough?) And by the way, this is in the interface, while the C++ example is in the implementation.
Besides, that's Haskell code that happens in practice. This is one I've just looked at, if I did some research I would certainly come up with more egregious code (maybe even mine). This one probably isn't even problematic (it's hard to say from the interface), but in general, mixing those extensions does lead to some very interesting problems from time to time.
Haskell has the same excessive complexity problem that C++ suffers. I do think this is the right thing to do right now. But I can't imagine it not looking as dated in 4 decades as C++ is now.
Honestly for me… C++. C++ but with restricted and consistent feature usage at every level of the stack. This means no stdlib, no stl, no boost. Writing your own pared-down standard library is actually not that hard if you make sure none of the calling code hits edge cases. 90% of boost just makes sure it's robust in the face of anything (classes that are movable but not assignable, initializer list constructors that behave differently, classes that overload unary &, etc… just weird stuff). Honestly the only reason I do this is simply because I like writing fast code and C++ is a good tool to do that. It would take me longer to become equally proficient in Rust, D, etc, than to just write 100% dependency-free C++. I mostly work on programming language implementation though, so libraries are less of an issue than in other possible situations.
D has been catching my attention a lot though. I just wish it had something kind of like C++'s move semantics, to make implementing owned pointers (C++ unique_ptr, Rust Box, etc) possible. Maybe it does and I just haven't seen it used yet. The other problem I have with D is that most libraries seem to rely on the GC.
Re: move semantics and unique_ptr in D, take a quick peek at std.typecons (unique, refCounted) and std.algorithm.mutation.move. I haven't used them, and they are library code (and so not as well specified as C++'s counterparts), but you might find them useful. There's been good progress on the @nogc front in the standard library, too, hoping to see continuing improvements there.
My personal worry with D is that the language changes a bit faster than, say, C++ or Rust. I don't know how whether the code I write today will still compile in five years. I wouldn't mind a feature freeze on the language design and the existing stdlib APIs.
The main D people (Walter and Andrei) and/or the forums say that there is work in progress to remove GC dependency from some of the libraries as an option. Not sure of the progress or rate of it though.
Edit: Sorry, should say "main D architects" - there are many other people involved in developing D.
The STL is generally nice, I agree, and I really miss the separation of algorithms and containers in every other language.
Generally, however, I'm not really a fan the ‘generic programming’ paradigm the STL (and boost) are based around. In C++ it quickly leads to an explosion of complexity.
And as for the best part of C++, RAII and sparing use of templates. ;-)
Rust? Go?