I really like Rust but there are lots of situations I wouldn’t use it. Some examples:
If I want very strict control over dependencies, a very small number of dependencies, or dependencies with specific/trusted origin.
If I was building software that won’t be actively maintained for years but might need adjustments later. The Rust ecosystem is a fast-moving target and upgrading a library could cause a huge cascade of other changes.
For the most hassle-free integration with an important library like Qt, particularly if a Qt GUI is the main point of my application.
Most web front-end. Using WASM to control the DOM with glue code is using a sledgehammer to crack a nut.
(?) Probably most event-driven apps like GUIs. Rust’s lifetimes mostly stay out of your way but they only work on the stack. Synchronisation between potentially multiple threads is very in-your-face and explicit, compared with say Java’s “synchronized” methods. It’s only early days for Rust GUI frameworks so I will wait and see. Maybe they’ll come up with something great.
I’m most curious about your thoughts on GUI apps: For Qt, is the main problem right now the fact that no complete bindings exist or is Rust fundamentally problematic for Qt integration? If Rust had a complete binding of Qt or GTK libraries, would you use Rust as opposed to the framework’s native language (C++ and C respectively)? What’s currently your favourite language for GUI development and what makes it suitable for GUI?
www.areweguiyet.com says that “Rust’s expressiveness and high level abstractions make it ideal for building intricate and complex user interfaces.” What do you think of this?
Most of my GUI experience is with Cocoa/UIKit (Mac/iOS). ObjC and Swift will let you play fast and loose with concurrent access to state and this is extremely convenient, though leaving the potential for a crash.
A Window might conceptually own a Button1 and Button2. So far this makes sense - if the Window is destroyed, its buttons should also be destroyed. Now imagine we attach an action to Button1 that disables Button2. Perhaps this “action” is a closure. Now we have an independent code block that has a reference to perform a mutating action on Button2. In ObjC you can simply do this by having a pointer to it. Rust won’t have a bar of it unless you use explicitly use reference counting and mutexes. It’s not just UI actions either - scheduled timers, URL downloaders and all kinds of other components need to take ownership of UI at spontaneous times.
Explicit mutexes aren’t the only option - the UI library could abstract over the UI elements so the mutexes are hidden from you - but then you’ve just replaced Rust semantics with Java/ObjC synchronisation so why are you writing Rust? Alternatively you could replace this very convenient event-driven design with a single “processing” function where you temporarily have mutable access to everything - I read about that in the design for one library. I didn’t like the sound of it.
There are options. None of them feels as ergonomic as the dangerous status quo that I’m used to. As I suggested, I’m not yet convinced Rust is a bad choice for this, but any library will have to think carefully to make this not suck. For now I would rather use a battle-tested option.
For Qt and GTK it would be okay if the bindings were high quality and there was good documentation/examples. I am skilled in neither and wouldn’t want the extra hassle of “making it work in Rust” unless this was outweighed by other advantages.
I really like Rust but there are lots of situations I wouldn’t use it. Some examples:
I’m most curious about your thoughts on GUI apps: For Qt, is the main problem right now the fact that no complete bindings exist or is Rust fundamentally problematic for Qt integration? If Rust had a complete binding of Qt or GTK libraries, would you use Rust as opposed to the framework’s native language (C++ and C respectively)? What’s currently your favourite language for GUI development and what makes it suitable for GUI?
www.areweguiyet.com says that “Rust’s expressiveness and high level abstractions make it ideal for building intricate and complex user interfaces.” What do you think of this?
Most of my GUI experience is with Cocoa/UIKit (Mac/iOS). ObjC and Swift will let you play fast and loose with concurrent access to state and this is extremely convenient, though leaving the potential for a crash.
A Window might conceptually own a Button1 and Button2. So far this makes sense - if the Window is destroyed, its buttons should also be destroyed. Now imagine we attach an action to Button1 that disables Button2. Perhaps this “action” is a closure. Now we have an independent code block that has a reference to perform a mutating action on Button2. In ObjC you can simply do this by having a pointer to it. Rust won’t have a bar of it unless you use explicitly use reference counting and mutexes. It’s not just UI actions either - scheduled timers, URL downloaders and all kinds of other components need to take ownership of UI at spontaneous times.
Explicit mutexes aren’t the only option - the UI library could abstract over the UI elements so the mutexes are hidden from you - but then you’ve just replaced Rust semantics with Java/ObjC synchronisation so why are you writing Rust? Alternatively you could replace this very convenient event-driven design with a single “processing” function where you temporarily have mutable access to everything - I read about that in the design for one library. I didn’t like the sound of it.
There are options. None of them feels as ergonomic as the dangerous status quo that I’m used to. As I suggested, I’m not yet convinced Rust is a bad choice for this, but any library will have to think carefully to make this not suck. For now I would rather use a battle-tested option.
For Qt and GTK it would be okay if the bindings were high quality and there was good documentation/examples. I am skilled in neither and wouldn’t want the extra hassle of “making it work in Rust” unless this was outweighed by other advantages.