It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned against when compiling with the (hopefully standard) -Wall -Werror, implicit copy constructors can either be deleted or this particular issue can be avoided by using a unique pointer (which has no copy constructor, hence the enclosing classes’ copy constructor is also deleted), I don’t quite get the issue with memory overlap, which is mostly an issue of a function receiving the wrong number set of arguments for the way it is written. The bit about broken iterators is actually nice, but in this case could be avoided by handing an external function two const_iterator which then cannot be changed. I don’t get the problems with "A dangerous switch" and "A broken semicolons", both seem sensible constructs and if you have bugs, you have bugs. Multithreading works as expected, except that using C++11 <thread> would probably have been nicer and one would have to explicitly make e.g. the lambda passed to std::thread mutable.<p>All in all, yes, Rust seems to be a nice language and in particular the template system looks somewhat more understandable, but please don’t write "Comparing Rust and C++" when you’re not actually using C++ but some weird mishmash of C and C++. If there are new, delete or pointer arguments in functions in your code, you’re most likely doing it wrong.
These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently.
Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all).
And yes, most of us will agree that header files suck and the rust approach here is nicer.
That template error message are also PITA is also well known - but on the other hand templates are different (and more powerful) than generics.<p>On the other hand there are still a few constructs that I'm using using often enough in C++ that have currently no sane representation in Rust and that are astonishingly never mentioned in these articles:<p>- Everything that you use the friend keyword for. In Rust there is no way to access private data defined in other file (because that will automatically be another module which is also something I disagree with).<p>- Most things related to inheritance and interfaces. Composition is not always a better solution and Rusts traits seem still more suited for compile-time polymorphism than to runtime polymorphism. As an example try to find the equivalent of a `shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing` in Rust. And yes, I want to be able to use both afterwards.<p>- <i></i>Enabling<i></i> concurrency. Some people might disagree but I think Rust is currently mostly good at preventing multithreading issues - but not at providing good and easy ways to enable it. E.g. something like boost asio would be between hard to impossible to implement in Rust because the safety mechanisms disagree with callbacks that mutate state or Future objects (which are similar to callbacks). For some things using low-level primitives like channels (aka queues) and creating new threads might be fine, but there are also enough cases where you would prefer a simple singlethreaded eventloop.<p>All in all I think there are still enough areas where I think Rust still is (unfortunatly) no real alternative for C++. And as long as that's the case I think writing such biased articles isn't fair.
I've flagged this because not only is it an unfair characterization of C++, it's also using a version of Rust that is six months out of date.<p>As a Rust fan, I don't think we need to resort to cheap shots. The language stands well enough on its own; misinformation and propaganda pieces won't get us anywhere.
Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.
Comparing languages with constraints which were laid in bedrock 30 years apart is fairly uninteresting. C++ is constrained by its compatibility with C, and always will be. Even C++17, which will be the biggest shift in the language ever, won't change this.<p>I see very little evidence that most programmers actually care about the advantages Rust <i>the language</i>, as specified today, brings. I'd contest that these days the biggest reason competing languages like Go, Rust, Python, PHP and Java often trump C++ is less to do with the language, and more to do with these languages having sizeable and fairly decent standard libraries. Programmers want to get shit done.<p>The C++ standard library is <i>tiny</i> and has seen fairly paltry growth over the years, with only modest introductions in C++11 of things like regex and threads. If a set of filesystem, HTTP, networking, and serialization libraries were part of the standard, and well implemented, we may well see a different landscape.
While I love what Rust is trying to achieve and hate the many, many issues C++ has, this reads like a blatant propaganda piece.<p>It's not comparing C++ with Rust, or at least not fairly. It's just listing the problems of C++ that Rust is trying to solve. Someone well versed in C++ could easily write an article with the same title and list a dozen reasons why C++ is superior.
One of the main problems of C++ is that programmers treat it as C with classes because that's what it feels like at the surface. They think they know it because it feels like C and many decide not to learn its patterns and details. From the examples given, it's clear that the author is not very familiar with C++ and is also comparing Rust to C++98 which is not fair. C++11 is almost a new language.
How does Rust handle multiple object files and dynamic linking? It seems to me that pretty much all of these guarantees break down if the compiler can't see the source code for the whole program at once.
I'd actually much rather read the opposite article: things that C++ excels at that Rust falls down on. I'm not an expert, but I think there's still allocation use cases C++ is better at.
Rust looks really promising. Unfortunately, the tooling just isn't there yet, it seems. Release a working plug-in for YouCompleteMe and I will switch overnight ☺
Does UB enabling code optimization? The 'dangerous switch' might run faster if the compile deduces that only two of the possibilities are valid?
The one thing I don't like about Rust is the implicit return. Looking at code, it's easier to spot a missing/extra "return" than a missing/extra ";".