I still get excited every time there is a new Rust release :D
> When using Cargo’s build scripts, you must set the location of the script in your Cargo.toml. However, the vast majority of people wrote build = "build.rs", using a build.rs file in the root of their project. This convention is now encoded into Cargo, and will be assumed if build.rs exists.
This is what I love about Rust's development. Rather than the developers just using their own ideas about how the Rust ecosystem will use a system, they instead wait for the ecosystem to come up with its own conventions. Once those conventions are organically established, they fold them into the official Rust tools.
It's the equivalent of finding product market fit. More times than not our ideas about what the market (in this case, Rust users) wants will be wrong. Better to just adapt to the market.
That's enough praise for now, so ... how about something not so great about Rust? I started building a password manager in Rust, because I'm not satisfied with the current options for password managers. This will be my first Rust project with a GUI and ... so far it's been very painful.
I've looked at GUI in Rust in the past but never tinkered because there were never any good libraries available. It's now Rust 1.17 and there are still no good options. For this project I landed on gtk-rs, but it's a nightmare of Rc's, RefCells, and borrow_mut just to get even the simplest UI working.
I'm not sure yet if this is an issue endemic to gtk-rs, or if Rc's and RefCells are a necessary evil in Rust whenever GUIs are involved. It's a bit hard to reason about ownership in this case, where your callbacks can be called at any time, and if they modify the UI that may trigger another, now nested callback, which may trigger yet another callback, etc. So it requires a lot of brain power to think about every borrow and what the lifetime should be.
Without thinking too much about it, I feel like things could be better. If Rust was driving the UI loop, and if the callbacks didn't have 'static lifetimes, then it might be possible shove the UI into an isolated struct and not have to deal with too many ownership and lifetime issues. But again, I haven't tried to think it through and it's irrelevant because there's no mature GUI library in Rust that would allow that.
Of course, none of that reflects on Rust itself, nor on the Rust developers. This is a third-party issue; it boils down to a lack of good GUI libraries. That's hardly surprising given how new Rust is.
For now, I'm blundering forward and just hacking together whatever mess of code works. The critical parts of the password manager are in a separate Rust library with unit tests, and the password database will have history/versioning on every entry. So I ultimately don't care if the UI code is ugly and hacked together. It's just more time consuming than it probably has to be.
You will be happy to hear that there was a GNOME Hackfest in Mexico recently, attended by several Rust team members. Some productive plans were sketched out for the future; as the GNOME project adopts Rust more and more, I expect this to get easier and easier.
> For this project I landed on gtk-rs, but it's a nightmare of Rc's, RefCells, and borrow_mut just to get even the simplest UI working.
> Without thinking too much about it, I feel like things could be better. If Rust was driving the UI loop, and if the callbacks didn't have 'static lifetimes, then it might be possible shove the UI into an isolated struct and not have to deal with too many ownership and lifetime issues.
I recently tried to implement a simple GUI using pure WinAPI, and I finally understod why Rc<Refcell<>> is necessary for callbacks. So far the experience is very mind-boggling.
We desperately need React-like UI library for Rust.
I've not delved much into GUI programming in Rust myself, so I'm just interested to hear any arguments for/against. As a more general point, I suspect a good Rust GUI framework will end up looking more in the spirit of React and the FRP approach, as ownership and the tendency towards immutable data have less friction with that approach.
I didn't try Conrad, because as far as I know it doesn't use any native components. Not that gtk-rs is much better, but I felt that at least GTK was "tried and true" versus a GUI entirely from scratch (Conrad).
My first attempt was actually with libui, which would give me native components on every platform, but they don't implement a list view which is the heart of a password manager's UI...
Ah, okay, that makes sense, particularly with the cross-platform aspect. Personally, my plan had generally been to just go with a client-server architecture. At least to start I'd only be targeting macOS in my hypothetical projects, so I had planned to just write the UI in Swift and Cocoa, and application logic in Rust. Unnecessarily complicated, but fun for a hobby project.
> When using Cargo’s build scripts, you must set the location of the script in your Cargo.toml. However, the vast majority of people wrote build = "build.rs", using a build.rs file in the root of their project. This convention is now encoded into Cargo, and will be assumed if build.rs exists.
This is what I love about Rust's development. Rather than the developers just using their own ideas about how the Rust ecosystem will use a system, they instead wait for the ecosystem to come up with its own conventions. Once those conventions are organically established, they fold them into the official Rust tools.
It's the equivalent of finding product market fit. More times than not our ideas about what the market (in this case, Rust users) wants will be wrong. Better to just adapt to the market.
That's enough praise for now, so ... how about something not so great about Rust? I started building a password manager in Rust, because I'm not satisfied with the current options for password managers. This will be my first Rust project with a GUI and ... so far it's been very painful.
I've looked at GUI in Rust in the past but never tinkered because there were never any good libraries available. It's now Rust 1.17 and there are still no good options. For this project I landed on gtk-rs, but it's a nightmare of Rc's, RefCells, and borrow_mut just to get even the simplest UI working.
I'm not sure yet if this is an issue endemic to gtk-rs, or if Rc's and RefCells are a necessary evil in Rust whenever GUIs are involved. It's a bit hard to reason about ownership in this case, where your callbacks can be called at any time, and if they modify the UI that may trigger another, now nested callback, which may trigger yet another callback, etc. So it requires a lot of brain power to think about every borrow and what the lifetime should be.
Without thinking too much about it, I feel like things could be better. If Rust was driving the UI loop, and if the callbacks didn't have 'static lifetimes, then it might be possible shove the UI into an isolated struct and not have to deal with too many ownership and lifetime issues. But again, I haven't tried to think it through and it's irrelevant because there's no mature GUI library in Rust that would allow that.
Of course, none of that reflects on Rust itself, nor on the Rust developers. This is a third-party issue; it boils down to a lack of good GUI libraries. That's hardly surprising given how new Rust is.
For now, I'm blundering forward and just hacking together whatever mess of code works. The critical parts of the password manager are in a separate Rust library with unit tests, and the password database will have history/versioning on every entry. So I ultimately don't care if the UI code is ugly and hacked together. It's just more time consuming than it probably has to be.