The issue holding most serious projects back is MSVC's historic lack of support for C++11 (and now 14/17) features. Thankfully, it looks like this is starting to change with MSVC 15 [0].

As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks.

[0] - http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...

There are more platforms out there than Mac OS X, GNU/Linux and Windows.

Many embedded platforms for example.

There are also enterprise customers that only allow for projects using the installed compilers, usually from the OS vendors.

May I ask you where do you work?

C++14 may be a bit new for some circumstances - but surely it's more mature than Rust (and is likely to retain that advantage).

> I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

Sure, but I’ve encountered some notable exceptions: LLVM projects (C++11), Playstation 4 games (C++11/14), QT5 (C++11) projects, et al.

None of those are the typical corporation code that most of us are exposed to.

Maybe? I was addressing your “I don’t see the opportunity where to use C++14 outside hobby projects.”

Compilers, games, and operating system components are archetypical systems software.

How many Fortune 500 do you see writing those?

Microsoft, Apple, IBM, Amazon?

How many C++ developers can apply to work on those world wide?

The point isn't what companies are using C++11 or C++14, rather what companies for the common C++ developer on the street.

Sometimes HN seems to think SV is the only place where programmers live.

Google is on C++11, or was when I left in 2014. They may be on C++14 now.

If your employer won't use provably stable and almost entirely backwards compatible language improvements, you might want to just find another job. C++ is a hard enough language that someone out there will be willing to be sane about the language version they use.

I know I'd only touch 20 year old C++ code with the go-ahead to refactor it into C++14. I'd argue that not adopting smart pointers, standard threads and mutexes, and auto type deduction make projects effectively unmaintainable at sufficient scale.

Back in 2005 my employer decided it was about time to move away from C++ in enterprise projects.

Actually in most of the enterprise projects I have been involved, C++ tends to be restrained to bindings to some feature not exposed in the chosen languages.

Changing employer doesn't matter, as most of these decisions come from the customers themselves.

It might work for in-house products, not so well when doing consulting.