He specifically says he likes Rust, just not for GUI app development. He also puts that on himself rather than blaming the language.
Which is not a hot take by any means, even in the rust community. A lot of UI based app paradigms don’t map easily to rust, outside of immediate mode UIs.
> I am too old to develop an appreciation for poetry or Rust
Basically he says he's in favor of Rust being used for security reasons but he doesn't like using it (which is fair, honestly, I don't like C# much either).
Also, there arguably no programming language that works well with UI, which is why we keep reinventing new paradigm every few years. People love saying Rust doesn't works well for UI because it doesn't works well for the old OO-based UI, but it's not how most people write UIs nowadays anyway: the current most popular paradigm for writing UI by far is React and its derivatives (or rather, the Elm derivatives), which isn't something I'm personally fond of but this paradigm at least works flawlessly with Rust (hence Dioxus).
And off course given that Tauri's default is about writing the app's GUI in JavaScript, the argument about Rust being a bad fit for GUI never made sense in the first place (and Icaza never maid it himself, by the way, see how there's no reference to GUI in the statement: “but I do not love it to write apps”).
There are definitely languages that work well with UIs. I’m not sure how you can make that clear cut a statement?
C++ and Python map extremely well to Qt which is one of the predominant UI frameworks. ObjC maps really well to AppKit/UIKit. Anything small talk derived has been a pretty strong fit for UI work
Just because new paradigms are made, doesn’t mean the old ones are inherently bad either.
> C++ and Python map extremely well to Qt which is one of the predominant UI frameworks
Qt used to be predominent, but it really cannot be said in 2026 given that there's probably two orders of magnitude between the number of React Apps and the number of Qt ones being made in this decade…
> Just because new paradigms are made, doesn’t mean the old ones are inherently bad either
Yet barely anyone uses the old ones anymore. Surely it must not be only because people like new and shiny things (React being more than a decade old at this point makes it far from “new and shiny” anyway).
> ObjC maps really well to AppKit/UIKit.
This example is particularly interesting given that Apple moved away from their old UI tech on favor of SwiftUI, which isn't OO-based.
1. I said “one of the predominant”, that there are other frameworks ahead of it doesn’t mean it’s not in the top set of UI frameworks. Especially for native apps and automotive / medical use cases.
2. I think you might be living in a bubble if you think “barely anyone uses them”. Qt still has massive use , entire industries are dependent on it.
3. This is a misunderstanding of SwiftUI. Many aspects of the underlying parts of SwiftUI are still AppKit/uikit based. It’s about declarative vs imperative, and about react style development. SwiftUI being better doesn’t mean that the old paradigms were inherently bad or unsuitable like you suggested
> Especially for native apps and automotive / medical use cases.
It used to be the case, but even those sectors made the move to web GUIs. Heck even the Windows start menu is an Electron app nowadays.
> 2. I think you might be living in a bubble if you think “barely anyone uses them”. Qt still has massive use , entire industries are dependent on it.
I'm not. I've worked in medical devices and train control systems, on projects that would have been Qt based a decade earlier but had moved to web UIs. I even have a friend working for a defense company who told me that the UI for their latest AA weapon system was built with web technologies! That even the most conservative industry out there has started migrating tells you all you need to know.
Qt is definitely in the “legacy technology” category at this point and has been for a while. That doesn't mean it's dead, like Cobol it won't die before the last system using it will, but it's still far less relevant than it used to be.
> SwiftUI being better doesn’t mean that the old paradigms were inherently bad or unsuitable like you suggested
I'm not saying they were unsuitable, but they definitely weren't good enough which is why the entire industry has moved to something else. (The said alternative is far from perfect either, though).
Even if React is technically the most popular, that’s somewhat moot because most folks who might be interested in writing desktop apps with Rust probably aren’t coming from a web background, but instead from old school desktop UI frameworks (AppKit, win32, GTK, Qt, etc).
For this crowd, the barebones “bring your own everything” style of React and its analogues and contortions required to write apps with complex UIs in a declarative framework are not very appealing. OO imperative UI frameworks with a wide and deep chest of batteries-included widgets still come out on top for this particular use case. Minimal declarative frameworks are fine for light utilities but become progressively more cumbersome every step beyond that.
> most folks who might be interested in writing desktop apps with Rust probably aren’t coming from a web background, but instead from old school desktop UI frameworks
You'd be surprised. A lot of people migrating to desktop apps are people coming from a web background (this is after all by far the largest pool of UI developers) who want something more efficient than electron.
“More efficient” is relative. While tauri and dioxus can lower the install size, they’re not going to be meaningfully more efficient than electron for memory usage or speed since Chrome probably does better than the other frameworks, and consistently across OSes which dioxus and tauri struggle with since they are dependent on the host OS’s web implementation. Slint is interesting here but then it’s more rust and less web coding.
Oh, "more efficient" here isn't a refence to Tauri. It's a reference to the parent comment's mention of "(AppKit, win32, GTK, Qt, etc)".
I work on a framework (Dioxus Native) which I think sits at an interesting intersection of "rust" and "web": it renders using HTML/CSS (custom implementation, not using a webview) but it uses Rust scripting instead of JavaScript.
What's "rust scripting"? I don't see any mention of it in the docs nor dioxus native roadmap and AFAIK https://github.com/DioxusLabs/dioxus/tree/main/packages/inte... is used as the interpreter although I can't for the life of me figure out where the JS engine is actually instantiated.
"interpreter.js" is for Dioxus's "web" backend which runs in browsers (who instantiate the JS engine). All it does is interpret "patch commands" to apply DOM mutations.
