Hacker News new | ask | show | jobs
by uneekname 671 days ago
I've been learning Rust and really enjoying it, but the primary downside (compared to C++) is the lack of access to the large, well-tested libraries that exist in C++. For example, my work would benefit from using the CGAL library [0], something that be nontrivial to rewrite in Rust. As much as I like Rust, at some point it's a better idea to use C++ to tap into libraries like that.

Does anyone have thoughts about how mature Zngur/CXX/etc. are for a project like mine? Would it be reasonable to invest effort in creating those bindings? Thanks.

[0] https://www.cgal.org/

4 comments

I’m using cxx/cxx-qt in a Rust QT app with substantial interop with Qt/QML and lots of C++ code (because Gpt/Claude make implementing some stuff easier in C++). It’s definitely mature enough because Qt’s libs are no joke.

At this point I have a Claude project set up with Cxx documentation and it autogenerates most of my bindings.

How was your experience using Qt with Rust? Is it awkward writing models and QObjects in Rust?

I'm a fan of QML and would love to use Rust with it if pleasant Qt bindings are finally there.

Do you know Slint?

I haven't really used it, but it seems to use the same idea, except it's native to Rust but comes with its own C++ and JavaScript bindings. I believe the project was started by some folks that left Qt (or some company that held the IPR at some point..).

I've checked it out and it's on my list of things to revisit in the future, but I've been burned in the past by using less-proven GUI frameworks, which is why I'm trying to stick with something like QML.

It's definitely something that looks promising, though. Hope to replace Qt with it in the future if it works out.

It's definitely a mixed bag and the ergonomics are rather shit due to the use of Pin<&mut T> everywhere, which requires as_mut() to reacquire mutable references for every (mutable self) method call - it's madness. There is also a lot of boilerplate in C++ and Rust to bind everything, especially since Cxx-qt bindings are very minimal. It didn't take long to figure out how to write my own and eventually generate them with Claude using Qt documentation but some core features like Rust getters aren't implemented yet in the core library so there's some stuff missing when writing custom QObjects.

Writing models has been surprisingly easy but there are still lots of annoyances like having to use QVariant to store everything because properties that refer to other QObjects must be raw *mut pointers. It's only taken a few hours each to write my models including a filesystem tree model. At this point I've got several examples of Rust models and C++->Rust conversions that I feed to Claude and it can easily write models from scratch or convert C++ models in the wild to custom Rust ones.

Sadly I haven't taken notes (I should) on my experience so far so my thoughts are rather disorganized. All that said, I've got instant hot reload of all the QML bits and I don't have to write C++ code with complex lifetimes so overall it's been a win.

Thanks for the reply
Do you have some specific usage of Claude to help? Or how do you use Claude/Gpt for this more precisely?
Not the OP but I have done similar things. Claude has a workspace option that let's you preset a set of documents (here the documentation of the library used) and a system prompt to be included when starting a new chat in the given workspace. Those will be in its, fairly large, context window (overall, independently of its intelligence, I have found Claude current UI to have an edge when dealing with files).
IMHO, he created RAG from documentation to provide more context for Claude, so he then can call Claude with a task like "Generate bindings in Rust language for C++ class Foo from the Bar library.".
Can you talk more any you Claude use?
Not the GP, but I use Claude with aider (https://aider.chat/) to write much of my chore code. At one point I even used it to write a whole mobile app, even though I have no experience with mobile.

   So, Zngur allows you to use arbitrary Rust types in C++, store them by value in the C++ stack, and call arbitrary Rust methods and functions on them. But it doesn't bridge any C++ type into Rust, since it is not possible with the same ergonomic
You want to use C++ libraries from Rust. This only does interop the other way.
Zngur does allow you to execute arbitrary C++ from Rust.

Unfortunately it chooses to just assume your C++ is sound, it does explicitly warn you that you're signing up for this, but realistically this just doubles down on the known bad assumption in C++ that programmers are infallible.

Rather than (like Rust's native C FFI) marking the arbitrary C++ as unsafe, Zngur chooses to have you explicitly opt in if you want your code marked unsafe. We know from years of practical experience that C++ programmers rely heavily on unstated assumptions for the correctness of code, a practice which does not scale. A very large proportion of the C++ stdlib itself has a narrow contract, yet few practitioners memorise these contracts and they're unchecked - disaster looms.

For calling C++ libraries from Rust, there is also https://crates.io/crates/cpp
It seems to do both:

https://hkalbasi.github.io/zngur/tutorial.html#calling-c-fro...

It sound like your quoted text is just saying that it’s not as ergonomic, you cannot use arbitrary C++ types directly in Rust, but you can use arbitrary Rust types in C++.

I've used cxx.rs to bind to the OpenCascade CAD kernel. It was a lot of work but the bindings seem to work well.
Zngur allows you to write functions operating over Rust types, adding methods to Rust types and implementing Rust traits for C++ and Rust types inside C++. So you can write a rusty wrapper for the C++ library inside C++.

If you want to immediately use a C++ library in Rust with minimal manual effort, check out autocxx [0]. Its generated api isn't very idiomatic Rust, and it uses Pin, moveit, ... but it covers a good percent of C++ apis and you can also make an idiomatic wrapper for it in Rust.

[0] https://docs.rs/autocxx/latest/autocxx/