It’s the feels, not the features :) Rust code feels like C++ code, at least when you’re reading it (I haven’t written any worth talking about). It puts the problem domain in similar terms, it has similar transparency (or lack thereof) regarding what it’s copying or allocating or whatnot, and so on. In that respect (!) they are closer to each other than C is to either—at least vanilla C, not a DSL (“language overhaul mod”?) like GObject. And it makes sense to target the C side of that divide in a new language (though again I lack the experience to say to which degree Zig succeeds in hitting that target).
Notably:
• Rust doesn't have inheritance. This makes a lot of basic C++ programming patterns unfit for Rust, and prevents 1:1 translation of C++ to Rust.
• Rust's generics may look like C++ templates, but they're not. Rust's macros behave more like C++ templates, and generics are closer to C++ concepts, but neither is a close match. C++ programmers are generally flabbergasted how hard is to make a function that takes any integer type in Rust.
• Even though Rust copied C++ moves, and has "RAII", the way these are used in practice ends up different due to having opposite defaults and different guarantees. Rust doesn't have constructors. Its closest equivalent of exceptions is for a different purpose. Rust's types are always movable, don't have meaningful addresses, can't reference own fields. Even C++'s std::string is hopelessly incompatible with Rust.
C++ has two string types, because of C legacy. Rust has two (and more) string types to express different modes of ownership. C++ is a complex language, because they keep adding more ways to initialize a variable. Rust has exactly one way. But Rust has many other features, mostly in its type system, to define thread-safety, memory-safety, and memory management in detail that is beyond what C++ can express. So "but they're both big" is glossing over all the reasons why.
However, C happens to be almost a clean subset of Rust. You can take a C program and translate it line by line to Rust. It won't be idiomatic, but may be easy to refactor into proper Rust. That's generally not true with C++, which requires rethinking everything from basic idioms and constructs to the overall architecture. This is why Rust struggles with GUI libraries, and the best-supported native toolkit is from C.
I can't see how that's possible, unless you litter your code with `unsafe` all over the place. Rust requires a lot of restructuring around ownership and borrowing to get your code to even compile.
The most common sin is C libraries taking just a pointer and hoping for the best, instead of pointer+length for buffers (slices). But that's also a "local" problem you can fix by adding an extra argument, generally not a major redesign.
Thread-safety tends to be worse to map, because C reasons about safety of function calls, while Rust about sharing of data types. So "it's safe to call foo unless option bar is set to -5" doesn't translate well.
The A:B syntax is not inheritance, but a syntax sugar for 'A where Self:B' bound.
The result is these remain separate traits without support for subtyping. dyn trait A:B can't be used where B is required, unless you have access to the concrete type and make a new vtable for B from scratch. There's WIP to fix that, but not here yet. The auto traits that look like subtyping are for built-in marker traits only.
Lack of data inheritance is painful. There's no support for fields in traits. Getters/setters are problematic due to borrowing all of self instead of just the field.
Traits can't have private or protected methods.
Traits aren't inherent to the types, so you have to import both the type and the trait to use it. It's messy and makes interface docs confusingly fragmented.
So Rust really really isn't an OOP language, even though you can put together an awkward-to-use imitation from a few ill-fitting features — but they use the same sigils as OO in C++!
You can enjoy my Rust version of Raytracing on one weekend, then again maybe not.
Just like being an FP language doesn't mean does it like Haskell. Many of which even predate Haskell's birthdate.
Plenty of ACM, SIGPLAN, IEEE, and EUROCOOP papers on the matter, including a few ones from a certain Simon Peyton Jones.
- Rust has interface inheritance with pretty much the same syntax
- Rust’s generics are monomorphized, exactly like C++ templates. They also have the same syntax. The only difference is that Rust generics are trait bound.
- Rust RAII is used exactly as it’s used in C++. Moves in Rust are destructive, while in C++ they are not. At the time where move semantics were proposed for C++ in the C++03 era, both types were proposed and the committee decided to go with non-destructive moves.
- Scope resolution syntax is also a carryover from C++.
When the words superset and subset are used in regards to C, C++ and Objective-C, it is quite a misunderstanding to describe C as a subset of Rust.
Yeah, there are some borrowed concepts, but it's a different language.
However, those who use C because they like the language would not enjoy Rust one bit and would much prefer Zig over it.