6 ms·

Rust doesn't have Qt

by jcelerier 4y ago

gavinray 4y ago
https://github.com/rust-qt https://github.com/rust-qt
- rvz 4y ago
  Not only those are rudimentary unofficial bindings but that looks unmaintained and is already out of date. Last updated 2021. So no. Rust does not have official Qt support.
  - juunpp 4y ago
    It's surprising to me that this was downvoted. Many a Rust project pulls several hundred Cargo dependencies that the developer probably hasn't even checked against basic things like outstanding bugs. The lack of standard package management in C++ sometimes is for the best.
- jcelerier 4y ago
  > https://github.com/rust-qt/examples/blob/master/widgets/basic_form/src/main.rs#L27 https://github.com/rust-qt/examples/blob/master/widgets/basi... this is ridiculous. rust does not have overloading ?
  - josephg 4y ago
    Nope! Rust doesn’t have function overloading like C++. What would that code look like in C++? (Rust has operator overloading - but that’s not the same thing).
    - jcelerier 4y ago
      here's the code translated to C++: https://gist.github.com/jcelerier/f76e3ee55037675db559e5062f7bd5bf https://gist.github.com/jcelerier/f76e3ee55037675db559e5062f... 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
  - tialaramex 4y ago
    Rust doesn't have any sort of ad hoc polymorphism. Of course, you would usually have a sensible name for these functions (maybe new_0a is a sensible name, I'm not a Qt programmer but I rather doubt it). 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?" })
    - account42 4y ago
      > std::vector has 10 constructors, they can't have different names 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().
steveklabnik 4y ago
It's not exactly Qt, but some former Qt folks are making https://slint-ui.com/ https://slint-ui.com/
- jcelerier 4y ago
  and knowing three of them IRL I really trust them to make something amazing - they already do especially with the work on microcontrollers and it will likely be my first choice if I have to show an UI from an uc - but API-wise Slint is quite similar to QML with a declarative tree approach ; having worked now on maybe 3 dozens of distinct projects using either QML or Qt Widgets (traditional widget tree retained API), ranging from one-shot software used at 1 event written in an afternoon, to car dashboards, to traditional WIMP author software, to freakin Unity3D plug-ins, I still find the widget API better for many, many cases (mainly in the technical and CRUD UIs which I mostly use my computers for). 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.
  - tialaramex 4y ago
    > 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 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.
dureuill 4y ago
This is the only correct answer. Although give it 10 years and that issue should be resolved.

Rust doesn't have Qt

gavinray 4y ago

https://github.com/rust-qt https://github.com/rust-qt

rvz 4y ago
Not only those are rudimentary unofficial bindings but that looks unmaintained and is already out of date. Last updated 2021. So no. Rust does not have official Qt support.
- juunpp 4y ago
  It's surprising to me that this was downvoted. Many a Rust project pulls several hundred Cargo dependencies that the developer probably hasn't even checked against basic things like outstanding bugs. The lack of standard package management in C++ sometimes is for the best.
jcelerier 4y ago
> https://github.com/rust-qt/examples/blob/master/widgets/basic_form/src/main.rs#L27 https://github.com/rust-qt/examples/blob/master/widgets/basi... this is ridiculous. rust does not have overloading ?
- josephg 4y ago
  Nope! Rust doesn’t have function overloading like C++. What would that code look like in C++? (Rust has operator overloading - but that’s not the same thing).
  - jcelerier 4y ago
    here's the code translated to C++: https://gist.github.com/jcelerier/f76e3ee55037675db559e5062f7bd5bf https://gist.github.com/jcelerier/f76e3ee55037675db559e5062f... 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
- tialaramex 4y ago
  Rust doesn't have any sort of ad hoc polymorphism. Of course, you would usually have a sensible name for these functions (maybe new_0a is a sensible name, I'm not a Qt programmer but I rather doubt it). 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?" })
  - account42 4y ago
    > std::vector has 10 constructors, they can't have different names 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().

steveklabnik 4y ago

It's not exactly Qt, but some former Qt folks are making https://slint-ui.com/ https://slint-ui.com/

jcelerier 4y ago
and knowing three of them IRL I really trust them to make something amazing - they already do especially with the work on microcontrollers and it will likely be my first choice if I have to show an UI from an uc - but API-wise Slint is quite similar to QML with a declarative tree approach ; having worked now on maybe 3 dozens of distinct projects using either QML or Qt Widgets (traditional widget tree retained API), ranging from one-shot software used at 1 event written in an afternoon, to car dashboards, to traditional WIMP author software, to freakin Unity3D plug-ins, I still find the widget API better for many, many cases (mainly in the technical and CRUD UIs which I mostly use my computers for). 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.
- tialaramex 4y ago
  > 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 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.

dureuill 4y ago

This is the only correct answer. Although give it 10 years and that issue should be resolved.