>Wait , so can rust generally be replace C++ code in most projects ?
In principle Rust could replace every line of C++ code in the world. The questions of how often it would be a good idea to do so, practical to do so, is harder to say. It is promising that this bluetooth stack only needed 4 lines of unsafe though!
Since the interop is zero overhead doing piecewise migrations is certainly possible, as has been going on with firefox, and curl and discussions of doing it in linux as well. You do complicate your build system and there is a non trivial amount of work to stitch the two languages together.
I think the answer is yes. Most C++ projects would be better served by Rust. However there are many caveats:
- I think that C++ devs are still more numerous than Rust devs.
- There are many excellent C++ libraries that don't yet have great Rust bindings. Furthermore it is unlikely that template-heavy libraries will ever be easy to use from Rust.
- C++ is supported on more platforms.
- C++ is more powerful. (Particularly templates). You rarely need more power than what is available in Rust but if for whatever reason your project would really benefit from heavy meta-programming C++ will be better. (I think this case is rare). Rust is also catching up, but the language development, especially around generics is fairly slow (which is probably a good thing)
IMHO, you're a bit too far in the other direction; there are areas where we've been working on actively improving, and there are still some things that C++ folks really miss in Rust. Doesn't mean we'll add all of them, of course, but there is desire for more, for good reasons.
There are generics and dependent types. But these are still gaining features and not nearly as powerful as templates and SFINAE. (but way easier to understand)
Macros are an option but don't have access to the same type information so often they solve different problems.
It is very hard to answer such a general question with a definitive answer, but Rust does want to be viable for the same sorts of things in which C++ is viable. As always, your mileage may vary.
- Rust has strong support for C ABI much like C++. So you can communicate between Rust and C++ via a C ABI.
- There are projects like https://cxx.rs/ to provide higher-level bindings between the two languages.
However I suspect that template-heavy/generic-heavy code will never be well supported. This is usually not an issue for the types of things that we are trying to bind.
Rust does not have classes, strictly speaking, though you can define methods on structs.
https://crates.io/crates/cxx is the simplest way to do an integration. It is slightly more work than "just plop in" but it's not incredibly difficult. It's harder than mixing C and C++ together, but then again, almost no pairings of languages are that easy.
Then C++ doesn't have classes either, you can put methods on structs though.
Rust people keep saying there are not classes, but all a class needs it the ability to put methods on structs. Private access to some of the internals is often useful, but doesn't need to be enforced by the compiler.
The issue is not "structs" v. "classes" per se, it's things like inheritance, vtables and RTTI (also other C++ features like templates and exceptions), that need special ABI support in C++ for which there is no Rust-side equivalent. (meanwhile Rust traits are quite different from anything in C++, although they're used similarly)
It largely depends on the definition of "class" you're using. You'll raise some eyebrows calling structs that can't support implementation inheritance "classes".
You can also have implement different associated functions based on properties of generic arguments, which is quite different in design from just attaching methods to a struct.
I mean, C++ has the "class" and "struct" keywords for a reason. (they are very similar, Rust structs are closer to "struct" than "class" though) There are a lot more things going on with C++ classes than syntax sugar for functions that have access to "this."
Also, while not in C++, in many languages, classes imply heap allocation, where structs do not.
What's the difference between struct and class in C++? IIRC the standard says they're the same except that members are public by default on struct and private by default on class. You could as well argue that C++ doesn't have structs.
The different allocation between structs and class objects in C# is a total head scratcher. Didn't it ever occur to the language designers that someone might want to choose how to allocate memory?
Maybe it was the era that I learned C++ (which was in the 98 days), but I was taught something closer to this convention, and didn't realize until just now there was such little difference by the book. Just bundling some data together? Use a struct. Doing more? Use a class.
I still think this distinction is useful overall, because there often is more of one in many languages, but I will be more precise when speaking about C++ specifically in the future. I would also still argue the same thing overall, that is, Rust does not have what C++ calls classes. Our structs are apparently even simpler than C++ structs.
It certainly makes sense to use struct and class to indicate what the type's role is. It's just good to keep in mind to avoid the confusion when you find the struct that has only pure virtual functions as members.
It's wise to use Rust in Security Critical Projects. Please see Google Fuchsia, they follow hybrid approach where critical stuff written in Rust and rest in C++
Has anyone here had success with a partial to Rust migration.