[Q6T46nT668w6i3m]

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-time processing. This is a significant advance.

What? C++11/14 solves these issues.

[pcwalton]

> What? C++11/14 solves these issues.

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.

[zanny]

My simplification of matters is that while C++ can now do everything right, it still easily lets you do everything wrong.

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.

[ssalazar]

> so for any project where you can't trust your coworkers aptitude towards correctness

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.

[copsarebastards]

Also, it's worth noting that "C++ provides a solution" is not "C++ solves these issues". Somewhere in any C++ codebase of significant size, someone has done it wrong and the compiler isn't going to tell you where.

[Q6T46nT668w6i3m]

Fair points

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

[Ygg2]

[Citation needed]

[Q6T46nT668w6i3m]

?

[Ygg2]

Based on what did you concludes that?

[scott_s]

No; modern C++ provides the tools for which disciplined use solves these issues. The problem is that one can silently subvert that discipline, and still introduce memory errors.

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.

[JoshTriplett]

> What? C++11/14 solves these issues.

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.

[pjmlp]

Only if you are allowed to use said features.

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.

[hendzen]

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

[pjmlp]

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.

[zerr]

May I ask you where do you work?

[lmm]

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

[Q6T46nT668w6i3m]

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

[pjmlp]

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

[Q6T46nT668w6i3m]

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.

[pjmlp]

How many Fortune 500 do you see writing those?

[djur]

Microsoft, Apple, IBM, Amazon?

[nostrademons]

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

[zanny]

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.

[pjmlp]

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.

[unfamiliar]

Care to elaborate? I don't see how it does.

[azakai]

Yes, in particular, iterator invalidation (problem 2 in that list) seems unsolvable in C++, as far as I can see.

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,

[Q6T46nT668w6i3m]

Yeah. It isn’t enforced, but it’s easier to mitigate.