Maintaining memory safety, thread safety, and avoiding UB is still much easier in Rust than C++. In C++ you have be vigilant to avoid a mistake slipping in. In Rust, you get a compile error if you make a mistake.
C++ has lots of bells and whistles, some of which Rust doesn't have (classes, to name one), but those aren't necessarily more important bells and whistles.
Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.
Rust's complexity isn't accidental unless it's being used for a job where it's overkill. Achieving memory safety in non-GC languages (let alone the degree of other static safety Rust enables) is easier in Rust than C++.
This feels like a gross generalization that's not applicable in many situations, and is immensely dependent on each individual person and situation.
I can write non-trivial performant code in Rust, including bindings across a C FFI much faster than I can weave together the equivalent code and build scripts in C++. Memory safety isn't the only thing Rust brings to the table. I sometimes don't because C++'s ecosystem is far developed for a certain application and it's not worth it for that particular situation. As with most things, it's about trade-offs.
C++ is definitely better but it's still not memory safe. Compared to Rust, you still have little tracking which thread has access to which variable at which time. Even in modern C++, you still have to care about iterator invalidation.
I agree that Rust is the better language because it gives you the safe tools by default.
Smart pointers are no panacea for memory safety in C++ though: even if you use them fastidiously, avoiding raw pointer access, iterator invalidation or OOB access will come for you. The minute you allocate and have to resize, you're exposed.
I'm not answering your question here, just saying my opinion on C++ vs Rust. I think that the big high-level difference (before diving into details like ownership and the borrow checker) is that C++'s safety is opt-in, while Rust's safety is opt-out. So in C++ you have to be careful each time you allocate or access memory to do it in a safe way. If you're working in a team, you all have to agree on the safe patterns to use and check that your team members are sticking with it during code rewiews. Rust takes this burden from you, at the expense of having to learn how to cooperate with the borrow checker.
So, going back to your question, I think that the answer is that it depends on many factors, including also some non-strictly-technical ones like the team's size.
The comparison I like to make is that Rust is the safer/modern version of C++'s memory model. It's in a different class from most languages, but trying to apply all the latest lessons and techniques.
Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made abstractions.
The one everyone mentions is that Rust gets memory safety without garbage collection. But there are cooler things, like being able to implement units in the type system. Rust also gets safety right in the sense that its defaults are good - its primary random number library has ChaChaRng and IsaacRng instead of a Mersenne Twister, for example.
The sensible library design goes everywhere, from Rust's functional roots, high-quality zero-overhead iteration protocol (none of the mess that C++ gives you) to simple things like a well-designed composable hashing standard.
Even stuff like comparing C++'s move, copy and constructor semantics are much nicer in Rust, and in most cases even lower overhead: everything is a memcpy and is implemented automatically.
I can go on. Rust is one of the few languages that IMHO gets string handling right, and has good unicode support from the outset. It's easier to write error-proof filesystem code than any other language I've used. Threading isn't a mess.
There are disadvantages, such as Rust being one of the hardest languages to learn. Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. There are lots of nonlocal typesystem effects, largely due to the thirst for safety.
But it's a good language. Definitely one of the most exciting I've seen in a while.
Rust is not the right choice because it's trendy, but because it provides memory and thread safety properties that are hard to enforce in C++. For systems software the advantages are huge.
Oh really? It's hard to believe that C++ could not achieve better performance with hand-tailored memory management than safe rust. I can understand that unsafe rust should perform about on par with C++.
All of these things have a larger cost than Rust: you're forced to use pervasive reference counting and very defensive data structures. Rust allows you to get away with pointers deep into other things, as well as aggressive data structures, all in safe code.
Rust also has reliable use-after-move defense for arbitrary resources (not just vague dynamic protections for only the memory resource), and defends against data races. That is, Rust has true safety in a way that can give higher performance than approximate safety in C++.
The main things that Rust offers over C++ are memory safety and better concurrency via data race freedom. There are other nice things too, like better macros, strongly typed generics, and pattern matching, but those two are the main highlights.
That being said, some projects are legitimately OK with some memory management errors and/or races creeping into production, in exchange for a lower learning curve in that area. If this describes your project, and you're happy with C++, then keep using C++.
(Note that I don't believe that "I write modern C++ so I never make memory management errors" is virtually ever true. Every large C++ app I've ever seen has fallen to some memory error or another. I think "I don't care (enough) about the errors" is a legitimate reason to use C++, but "I don't have to care" isn't.)
It's more complicated than that. Compilers love restrictions, because that means they can optimize more aggressively. And there are features that Rust doesn't have that C++ does have that can make Rust faster; for example, because Rust doesn't have move constructors, moving is an incredibly cheap operation, whereas it can execute arbitrary code (including throwing an exception!) in C++.
There are also... I don't know how to frame this, social issues? Rust's guarantees often let you do some very aggressive things that you could write in C++, but wouldn't, because it's not maintainable. For example, if you must use reference counting, but don't need threads, Rust has a split between Rc<T> and Arc<T>. You can afford to not use the atomic version in Rust code because if you ever refactor later, you know the compiler will catch this for you, whereas you're just asking for latent, hard to track down bugs if you tried this in C++.
This goes both ways; there is some stuff that C++ is better at than Rust too. It's more complex than "unsafe Rust lets you do anything C++ can do directly and so if it's 100% unsafe in Rust it will be the same speed and if it's safe Rust it will be slower."
I think you're reading into the comment too much. Rust by definition, will create a safer variant of whatever similar code you write in C or C++. This isn't really debatable, things like bounds checking on arrays, strongly typed error results, thread safe memory sharing semantics. These will absolutely guarantee that in general you will have safer code in Rust.
What I said is that it might take you longer to write it in Rust, than something similar in C/C++, but you won't have some of the guarantees you get from the Rust semantics. So the tradeoff is up to you; write code faster, or write code safer.
Why would you think that Rust is "far simpler" than C++? Exactly the same concepts (with extras on Rust's side because of the ML-like constructs) must be learned for both, except they're distributed differently on the learning curve.
And I wouldn't say that Rust's safer than Java either. Memory access errors are basically non-existant in Java and it has quite robust concurrency primitives and libraries.
It is better, definitely safer. But it's not perfect. I write rust on a daily basis. I've written a lot of C++ in the past. It's safer, but I have memory safety issues in both. It's more a matter of degree.
For a large existing code base that are well written I think it's easier to improve the safety of the existing code than rewrite it completely in a safer language.
In short: the type system is significantly more expressive and encourages domain modeling that tends to lead to fewer errors; "if the compiler says it's OK, it'll be OK" isn't strictly true but it's often pretty close. Rust also offers stronger guarantees around memory safety than C, as well as C++ as commonly practiced. (Which is to say, you can write very memory-safe C++, but you will work at it.)
reply