You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data.

I would also argue that Rust is a better solution to the first two issues. Modern C++ does not solve the problem of use-after-free (dangling references and invalid iterators are very possible, and common in large codebases). This is something that I don't believe C++ can solve without becoming a radically different language. Furthermore, Rust forces you to use the right patterns unless you type "unsafe": this is, again, important for security, reliability, and developer productivity, reducing the amount of time you spend in the debugger.

Rust compels correctness, so for any project where you can't trust your coworkers aptitude towards correctness (and that is to say you even trust your own) Rust is an insane productivity booster. We could have avoided millions of hours of work and thousands of zero day and system destroying bugs if we had OS cores written in a language like Rust.

So, for any non-trivial project. People will make mistakes, no matter how skilled or experienced they are. Catching these mistakes at compile-time can be a huge gain for security and stability.

Though it remains to be seen is what kind of maintenance/development burden these constraints introduce over the longer term lifecycle of a software project.

Rust’s synchronization primitives are immature — they’ve been rewritten once or twice in the past year or so — but cool from a usability perspective.

edit: oh, hello pcwalton. I suspect you knew this already. :P

Rust enforces memory safety at the language level. C++ itself does not "know" about memory safety. This difference, to me, is huge. You can still opt out of memory safety in Rust through unsafe regions, but the fact that Rust provides memory safety guarantees to non-unsafe regions is, to me, a change in kind, not degree. When the only thing enforcing memory safety is disciplined use, it's still too easy to make a mistake.

Sure, it solves some of those problems if you use exclusively smart pointers and vectors, and never use the built-in language pointers and arrays. What forces you to do so, when '*' and "new" and [] are right there?

Rust pushes you towards the right solution by requiring an "unsafe" block if you use raw pointers or arrays. That doesn't prevent you from using them (such as in the implementations of higher-level constructs or FFI calls), but it does hint that they're the wrong solution for everyday programming.

Many C++ codebases out there are still pre C++98.

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

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...

Many embedded platforms for example.

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

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

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

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.

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.

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.

I've hit iterator invalidation in a new c++11 codebase. Perhaps c++14 offers something to help it that I'm not aware of?

edit: "unsolvable" in the sense of the language making it impossible,