I've seen this opinion now twice in short succession on HN. Issues with C++ safety aren't just a matter of a dangling pointer that should've been a unique_ptr or shared_ptr. It's massively naive to think that this would in any way be comparable to Rust.
That's not even considering the reality that no real-life C++ codebase seems to survive on those modern C++ features alone. (If it did, I presume Mozilla would've rewritten Firefox in C++11/14/17 instead of Rust. Oh wait, they already use C++11...)
While I agree, I would point out that in the same way that "safe" Rust is a usable (if difficult to get used to) subset of "unsafe" Rust, there also exist usable safe subsets of C++ [1]. Tooling to enforce that Rust code strictly conform to the safe subset, of course, already exists (and is built into the compiler). Such enforcement tools do not yet exist for C++ code, but I think they're coming. And I think they'll probably support safe subsets that are more convenient/intuitive/easier-to-use than (the current version of) safe Rust.
I wonder if adopting Rust to avoid the pervasive unsafe code in C++ isn't a little bit akin to adopting Esperanto to avoid the pervasive cursing in English. I mean, there does exist a non-vulgar subset of the English language, even if it's difficult to persuade people to stick to it :) But then, if all the cool kids are talking Esperanto...
> (If it did, I presume Mozilla would've rewritten Firefox in C++11/14/17 instead of Rust. Oh wait, they already use C++11...)
I think this may be a missed opportunity by the Firefox developers. If you look at the code, they're still using new/delete and raw pointers targeting dynamic objects. I presume that a lot the code has survived from the pre-C++11 era. I think converting their code to a safe subset of C++ (like SaferCPlusPlus) would be quicker and require less effort than a rewrite in Rust.
[1] for example (shameless plug): https://github.com/duneroadrunner/SaferCPlusPlus
Where did you get this idea that "safe" Rust is a subset of "unsafe" Rust? Your whole premise here perhaps qualifies as not even wrong: this is not how safety in Rust is conceived or conceptualized.
[1] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...
I think you might be confused about what Rust offers and from where Rust's safety is derived. There is no "safe subset" of Rust. As far as I know, that is a nonsense phrase.
const string& s = max<string>("a", "b");
It makes a dangling reference that will crash when accessed. In Rust that's impossible.I think you are exaggerating. Most projects with any user base provide ready binaries which able to get going pretty fast.
"it's so bad that big C++ projects like Firefox and Chromium basically write their own scripts that download and build dependencies, and simply commit the source code of the libraries they use directly into their own tree."
I would not call this 'bad' but resilient.
"Replicating is bad" is a non value adding rule of thumb, imo.
That said, yes, it's very hard to start incorporating third party libraries to C++ when compared to any other language.
But hey, modules are coming in the next couple years. Should really help with this.
But what about the dependencies of those binaries/libraries? Manually playing that cat and mouse game just sucks.
I believe there is some thought being put into making a C++ package standard [0], which would do wonders for the language. in my opinion half of the reason Node took off is because npm is so easy to use, and people are getting excited about Rust partially because Cargo is so well thought out. Now I might be wrong here, but I think if you took modern C++ (no raw pointer manipulation) and combined it with a good package manager, I think you would pretty much erase any advantages Rust offers.
[0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p023...