Hacker News Reader

Comment by d33 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com