5 ms·
can someone eli5 why rust is okay but not c++11 variants?
by DesiLurker 4y ago
can someone eli5 why rust is okay but not c++11 variants?
- Arkanum 4y agoMy limited understanding is that rust provides significant advantages in terms of memory safety[1], that should reduce the chance of errors and bugs, whilst c++11 does not provide these same advantages. [1] Comparison of memory safety of c vs Zig vs Rust (from elsewhere in the comments): https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/
- boris 4y agoC++ burnt through a lot of good will in the C++98 era where it was admittedly a hot mess (and all the compilers where buggy dumpster fires). Now on one hand we have people who publicly and loudly swore off touching C++ ever again based on this experience (and even more people parroting the “C++ is a mess” statement without any experience) and on the other the excitement of Rust with all the hype making people invest a large amount of effort into learning it.
- jcranmer 4y agoRust's design has given more thought for how to work in the kind of programming environment that the Linux kernel sits in than C++ (even C++11) has. Specifically (and this is no longer quite eli5), Rust's freestanding mode--working without a standard library--is somewhat fuller and more fleshed out than the C++ freestanding mode. Now, the sibling comment that points out that C++ gained a bad reputation pre-C++11 is probably a bigger reason for it not being seriously considered whereas Rust is, but there are some technical reasons where Rust does better than C++.
- woodruffw 4y ago'jcranmer gave a good summary, but to add one or two more points: * It's very difficult to predict allocation patterns in C++ (even modern variants) from just the source code. An innocent looking object allocated on the stack might have a nontrivial constructor with all kinds of side effects. Rust, while being slightly less explicit than C, is much more explicit than C++. * Modern C++ doesn't actually play that nicely with C. C++'s aliasing rules and casting rules keep getting more and more strict, whereas kernel programming lends itself to a lot of "bag-of-bytes-to-struct"-style programming. It would be very unfortunate if adding a C++ compiler to the kernel's build broke pre-existing C code by detecting UB in the context of C++ and decided to simply erase it.
- ncmncm 4y agoNeither of those is correct, as a legitimate reason. Rust does everything C++ does, as far as things happening invisibly. Everything Linus famously ranted about is there. And, Rust has even more incompatibilities with fast-and-loose C memory use. There are reasons why C and C++ compilers have "sanitizer" modes. Those identify places where code would be surprisingly elided. Yes, C has those too.
- rcxdude 4y ago>Rust does everything C++ does, as far as things happening invisibly These 4 things do not happen invisibly in rust: code running on struct creation (it will be an explicit ::new() call) code running on struct copying (it will be an explicit ::clone() call) code running on struct moving (moving is always a memcpy in rust, no custom code can run). Error handling flow control (no exceptions, error handling will at minimum be marked with a '?'). (yes panic exists but this is basically for the same purposes as a kernel panic). Rust favours making things explicit, much more so than C++.
- woodruffw 4y agoRust famously does not do implicit allocation or implicit nontrivial construction. It also famously doesn’t do implicit construction when concrete parameter types don’t match the types in function signatures, which is a common source of side effects (and memory corruption) in C++. In general, Rust is more implicit than C, but significantly less implicit than C++. Moreover, the ways in which Rust is implicit are more consistent and less likely to introduce bugs.
- ncmncm 4y agoYou will need to cite evidence that implicit argument type conversion is a common source of memory corruption.
- woodruffw 4y agoI figured it rose to the level of conventional wisdom. I don’t have a source to cite, because I’ve only dealt with it in random codebases. As an anecdote: I had a codebase where a nontrivial constructor contained a “registry” of created objects, for introspection. The design contract for that part of the API included the assumption that all constructions would be explicit, but it wasn’t actually enforced. Later, someone did some subclassing and added some APIs that inadvertently performed a converting construction, resulting in broken invariants around offsets and members in the registry. Was it a good design? No, it was terrible. But nothing stopped someone from writing it, and the codebase otherwise “did everything right” (C++11, warning flags out the wazoo, fuzzing, unit tests, etc.) It was a real pain in the ass to debug, and it fundamentally couldn’t have happened in a Rust codebase. And that’s just one tiny corner.
- seabrookmx 4y agoOther commenters have good points, but don't underestimate the fact that Linus doesn't like C++.
- ncmncm 4y agoThis, despite that Rust has every single thing Linus hated about C++.
- tialaramex 4y agoThis claim would be a lot more compelling if, when confronted, you were able to list the things "Linux hated about C++" and show how Rust has them.