Rust doesn't have Qt
But when I say "Rust does not have Qt" this is actually not what I refer to.
A big point of Qt is that you have a complete consistent library with an event loop that will handle everything from GUI to network / serial port communication / media playback / JS scripting / database access / ... transparently, with APIs that are fairly cohesive. With Rust whenever I looked at it it was async API flamewar and the need to use 50 libraries that all have slightly different conventions, namings, etc. Qt brings consistency, just like boost does, and that's why I like using those ; most of the time I don't even have to think about what the name of something is going to be in a class / type I've never used, because it's obvious from the naming scheme of the library.
A kitchen sink library, re-implementing absolutely everything. I do mean everything there's even a QString to use because heaven forfend a C++ library wouldn't have its own custom String class...
The temptation to build kitchen sink libraries is exactly what this proposal seems to be fighting. No, I don't expect they will win.
- An barebones API that's hard to use (missing really basic functions like contains() and split(), although they might come on C++2-god-knows-fuck-when)
- Until recently (C++20), didn't have a convenient way to format strings. QString::args() isn't that nice, but at least it's far better than using the stream operators. It's just sad that people were hyped that std::format was finally coming in the year two-thousand-fucking-twenty...
- Dealing with encodings and locales. Unicode conversions, anyone? Like, C++17 actually even deprecated the whole <codecvt> header! I understand it was absolute shit, but the audacity to remove it without presenting an alternative...
yes, and having written projects in both the kitchen sink and the many-libraries approaches, the one that consistently shipped software fast is the one with the kitchen sink framework
Although give it 10 years and that issue should be resolved.
So no. Rust does not have official Qt support.
this is ridiculous. rust does not have overloading ?
(Rust has operator overloading - but that’s not the same thing).
Rust certainly brings a lot, but I would really doubt of the sanity of anyone who would take the rust code over the C++ one here
Rust's "constructors" aren't magic, whereas the C++ constructors are magic, so they need ad hoc polymorphism or you could only have one constructor for each type.
Let's compare familiar types which weren't built using some sort of FFI magic, C++ std::vector and Rust's alloc::vec::Vec.
std::vector has 10 constructors, they can't have different names, so they're distinguished by their parameters, perhaps your IDE will prompt you with a list of options or you'll remember the parameters you need to do what you intended.
Vec::new() makes a Vec, Vec::new_in(allocator) makes a Vec using a specific allocator, Vec::with_capacity(4) makes a Vec with capacity for 4 things and so on.
Somebody else mentioned operators, note that Rust doesn't really overload operators either. In Rust the operators are getting implemented. If you don't implement an operator, then it doesn't exist, whereas in C++ the operators often have some pre-defined behaviour and you can change that using overloading.
For example if your type Doodad should like to be able to use the + operator on other Doodads, you can implement core::ops::Add<Doodad> for Doodad - now the + operator works when both sides are Doodads. If you'd like a += b; to work, you'd implement core::ops::AddAssign<Doodad> for Doodad. These traits require methods with the appropriate signature e.g. AddAssign::add_assign(&mut self, rhs: Doodad) saying this function needs a mutable reference to a but consumes b.
Oh, before I forget:
Because Rust doesn't have ad hoc polymorphism often people realise they wanted parametric polymorphism here. For example C++ 23 can almost do "bananas".contains("nanas") finally, but it uses a bunch of overloading to pull that off, since Rust doesn't have this, it chose to reify the idea that's filling out that slot in the C++ functions as a Trait, and it calls this the trait Pattern. So, all the places where you mean "You know, for matching strings" you can use any of the ways of matching strings because they implement the Pattern trait
"bananas".contains('b')
"bananas".contains("nanas")
"bananas".contains(char::is_whitespace)
"bananas".contains(MyCustomThing { "is it fruit?" })Except you can have static member functions (calling private constructors) if you do want that. Of course that doesn't compose as well as overloaded constructors which e.g. lets all constructors for a type T be accessed via std::vector<T>::emplace_back().