Viability of implementing/binding UI in Rust (cxx/autocxx/bindgen)?

[GavinRay97]

As comment implies, I'm curious whether you think this is feasible.

Would be very interested in this if the possibility exists -- I don't know very much Rust or C++ but I'd certainly rather write Rust than C++ 😅

[bepzi]

I'm still investigating this. Technically, with enough cxx glue you can do everything in Rust, but my gut instinct is that it would be much lower friction to just write the UI in C++ unfortunately.

There's also the thorny problem of how to safely pass data between the UI thread and the audio thread. Rust isn't the one creating those threads, so from its perspective there's only one thread, and we have to be exceptionally careful our C++ code doesn't try to concurrently access the Rust audio processor. If you look at the C++ AudioProcessor implementation, you'll see that every time it calls into the Rust implementation, it locks (or tries to lock in a non-blocking fashion) so that we guarantee there's only one mutable reference, just like how Rust wants it. I have no idea how this would work once we start involving a GUI thread that wants to read/write data to/from the audio thread.

However, I'd definitely prefer to do everything in Rust if I can, even if it's initially much harder than just using the JUCE C++ stuff. One thing that I could try is, in my AudioProcessorEditor implementation, I could get a pointer to the native window and then... I'm not sure. The crux of the problem is that the Rust code isn't the one creating the GUI thread or asking the host for the window.