4 ms·
> 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 wou
by duneroadrunner 10y ago
> 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.
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 https://github.com/duneroadrunner/SaferCPlusPlus
- none_for_me_thx 10y ago> in the same way that "safe" Rust is a usable (if difficult to get used to) subset of "unsafe" Rust 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.
- duneroadrunner 10y agoYeah, that's my point. Even though, unlike C++, (safe) Rust was designed to be (memory) safe from the start, it's notable that Rust and C++ end up (or will soon end up) in the same place - a "usable" safe language and an unsafe superset of that language. It's notable because before C++11, memory safe subsets of C++ could be considered not really "usable". But since the advent of C++11, there are memory safe subsets of C++ that are comparable to Rust in usability and performance [1]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-rust https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...
- none_for_me_thx 10y agoI should have said I think you are operating under false assumptions, are making invalid comparisons, and are therefore drawing unwarranted conclusions. 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.
- dbaupp 10y agoI think nonsense is rather too strong: Rust-banning-`unsafe` is a subset of the full language accepted by the compiler, and is safe. It isn't rare that people talk about the subset of Rust ignoring `unsafe`.
- steveklabnik 10y agoUsually, we describe unsafe rust as a superset of safe Rust. that is, unsafe Rust is exactly like safe Rust, but gives you extra things.