Rust and QML: a timely example | Hacker News Reader

Rust and QML: a timely example

vandenoever.info

144 pointsgilrain20 comments

Is it just me or it feels way too ugly? Multiple opaque layers of abstraction plus Rust kind of feels shoehorned when it's called from C++. Something tells me it's terribly difficult to write, debug and deploy. I don't exactly see the benefit of adding Rust here.

C++ and Rust are very different. A direct binding is near impossible. This project takes a pragmatic approach: the GUI part is QML/Qt and the logic part is Rust. The separation is quite strict. The demo application showcases more of the features than the blog does. Notably, the mapping between the Qt data models and the Rust code is something that makes development effective. This will be emphasized in the upcoming FOSDEM presentation.

https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...

As a Rust-curious C++ / Qt developer, I've been following this project with a ton of interest. Will the FOSDEM talks or slides be posted online?

Of course.

> I don't exactly see the benefit of adding Rust here.

From that perspective, there isn't any. Dyed-in-the-wool "QT app-devs", if there is such a category (KDE devs?) already have access to Rust libraries, in the same way they have access to most stuff in weird compiled languages: you wrap the library in a C ABI and call that. It's a well-understood process in QT land.

I think this project is more an effort to give Rust projects access to a native graphics toolkit (that happens to be QT) for adding a GUI to a previously CLI application. I could see, for example, the Parity Ethereum client (written in Rust) getting a native system-tray/notification-area widget written in QT.

There's a distinction between a Qt project calling Rust code via a C ABI versus a Rust program bootstrapping Qt.

The author hand-edits a C++ file, autogenerated by CMake. In that sense it still needs a C++ compiler as part of a build step.

A binding relying only on Rust and QML might replace the C++ boilerplate with a Rust equivalent.

The binding generator generates a binding from a JSON file. That gives C++ and Rust code. Additionally, a default Rust implementation is generated for convenience where the programmer fills in the application logic.

At no point is there a need to edit a generated C++ file. Any other build tool with C++ support could be used instead of CMake. What it should do is call rust_qt_binding_generator when the binding description changes.

The table in this blog shows what files are generated: https://www.vandenoever.info/blog/2017/09/04/rust_qt_binding...

> At no point is there a need to edit a generated C++ file

Well then maybe your example should reflect that, where a change is made in the C++ file replacing 'Simple' with 'Time'

`src/main.cpp` is not a _generated_ C++ file.

It can be seen inside the template project here:

https://phabricator.kde.org/source/rust-qt-binding-generator...

Rust has benefits over C++. But you cannot just port a project from C++ to Rust, especially if you use a Qt GUI.

To combine Rust with Qt you could use a language binding that wraps Qt in a Rust API. This is a very big undertaking and will result in an API that is not Rusty at all. Qt is a great toolkit but it does not have all the safety guarantees that Rust has. So the Rust API on top of Qt would have a complicated manual.

This binding generator creates code from a JSON description that is very limited compared to Qt or Rust, but it generates code that is good Qt and good Rust.

The generated code has no dependencies apart, obviously, from Qt and Rust and the generator itself is small and has no dependencies apart from Qt.

Yes, if you combine two languages, you get the warts from both languages and that is indeed uglier than using a single language.

A bit.

This is the reason why I have learned to only use first party SDK languages for production code.

Anything else that isn't supported by a platform SDK out of the box, means extra work writing FFI bindings, complexity (is the bug on the platform libraries, FFI bindings or runtime library of the new language), harder to debug (lack of support from SDK tools).

Of course, if the goal is to try to push SDK vendors to add support, then this is probably the only path to raise awareness.

> only use first party SDK languages for production code.

And this is a big part of why we can't have nice things and programming is stuck in the 70s. And regressing.

I understand the reasoning, it's just a terrible dynamic.

i think the benefit is more for Rust users who find they need to make a GUI. There aren’t many good options right now so this will probably be welcome.

I noticed that the repository is served from a KDE domain. Is this an official KDE project?

Also, How usable is this for building GUIs on Windows? Does it play nice with QT creator?

(I'm still inexperienced with QT development so please bear with me)

The project has no assumption of the platform that is used. It works with vanilla Qt projects regardless of IDE or build tool. Call rust_qt_binding_generator from your build tool to generate the binding files.

This project is different from most language bindings. With it, you generate a binding just for the code specific to your project. So interface the between Rust and C++ is very small. This project does not wrap Qt API in Rust code or Rust API for Qt. Instead of using a lot of energy to heat the whole house, you put on a sweater.

As someone who doesn't know KDE, what is the significance of having "official KDE" status?

The same as in any other platform.

Having official status, means anyone coding for the said platform can be confident that everything related to the platform infrastructure (IDE, libraries, debuggers, documentation, discussion forums, build systems) will take into account the language.

Anything that is just 3rd party will have integration issues, as one needs to rely on the language community to step up to sort them out, or even left in a zombie state as interest fades away.

Auto generated traits? Yuck.

I understand the trade offs and why this makes sense. But it hearkens back to some of extremely ugly parts of older Java frameworks.

Most time on the project is spent on making a sensible binding at all. The ergonomics could definitely be improved. Rust has powerful macros that could make it simpler to use these bindings. My development time is finite.

can that compile to asm.js and wasm?

Reply on news.ycombinator.com