Hello there, Yan from Teapodo here.
Yes, we structured our application around C++, and the Rust part is more of an internal library called from C++ via FFI.
We took this approach initially because I had done this before in another application[1], and I was quite happy about the result then.
Also, as we are a very small team (2 developers) developing a cross-platform application, we thought it makes sense to only use Rust to solve the hardest part first (i.e. the audio engine) and offload other complexities (e.g. a cross-platform GUI, reactive data binding, etc.) to some existing frameworks (Qt in this case), so that we are less likely to be overwhelmed.
We did end up with writing the whole application's data flow in Rust as well (e.g. the whole application state tree, the undo/redo, and all of the business rules such as audio clip size constraints, etc.). We did it because we thought it's also a pretty isolated problem, so the whole thing can be easily encapsulated in pure Rust without interacting to much with other systems.
Our experience of doing it this way was pretty good. We basically live in two worlds: the core Rust library and the GUI (in fact they are even separate Git repositories). We follow best practices in each worlds, and they interact with each other using FFI (in C).
The only negative side of this for us so far is that there are some manual steps involved when crossing the FFI boundary (on either directions), for example:
- When providing a functionality from the Rust library to the UI, we need to write an unsafe C ABI binding for each API we want to expose
- On the other direction, if we want to pass complex data structures from the UI to the Rust library, we would need to either interpret the data using C primitives or create an opaque type and require the UI to properly initialize the data
I believe there might be ways to make it more ergonomic (e.g. procedural macros, or some existing crates such as cxx), and we will certainly look into improving it at some point!
---
[1]: I built a Unicode tool for macOS and iOS, with the UI being written in AppKit and UIKit, and the Unicode data being provided by Rust.