Awesome, glad to hear that :) So, for Rust vs Go, honestly I had kinda wanted to learn Rust for a while and have only read a little bit of Go, and – this is goi

Awesome, glad to hear that :) So, for Rust vs Go, honestly I had kinda wanted to learn Rust for a while and have only read a little bit of Go, and – this is going to sound incredibly silly, but I'm not a big fan of some of the syntax and conventions from Go. For Recut, the choice was more between (a) coupling Rust with a web-based cross-platform framework like Electron or Tauri or (b) using C++ and Qt. I guess option (c) would be to write and maintain two versions of the app, one in Swift and the other in something Windows-specific, but as a solo developer I ruled that out pretty quickly. So - Rust vs. C++ - and would the Rust + JS be fast enough? I did some experiments to test out some of the things I was worried about, like rendering video frames, and sending data between the UI and Rust. I've had experience with C++ and Qt in the past, so that was a decent option. But I didn't love the idea of getting back into C++ and fighting with the inevitable hard-to-find crashes and race conditions and stuff. And, from building v1 of Recut in Swift, I came to really enjoy some of Swift's safety, too - like guard clauses that rule out null-pointer-related crashes. Rust seemed similar in those aspects. Given how it turned out, I would definitely choose Rust again. I think it might've been wise to try to learn more about the language and tackle some smaller toy problems first, instead of trying to learn it while writing the app. I didn't do much exploratory hacking, and ended up rewriting whole swaths of the video pipeline stuff multiple times. Like at least 5 times. But maybe that was the best way to actually learn it, too. I don't really know if I would've picked up the intuition for some of the patterns if I hadn't had to fight my way through it. So maybe there's some survivorship bias here haha.