9 ms·

People keep asking why TUIs in Rust and the answer is because the GUI situation in Rust is dreadful: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust

People keep asking why TUIs in Rust and the answer is because the GUI situation in Rust is dreadful: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gui-libraries.html https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-... Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint. No markup at all. None of the immediate mode things. No other languages. Definitely not GTK. I'm worried it will never happen for Rust and it will be such a missed opportunity.

goku12 11mo ago
You basically preempted nearly every single option, including an incumbent one. I don't believe it's fair to judge Rust based on its compatibility with Qt alone - something written in C++. Nothing against C++, but it's harder to get C++ and Rust to work together. You haven't addressed Iced yet, though going by your requirements, you're unlikely to be satisfied by it as well. Iced is not there yet, but it is the native GUI toolkit of the Cosmic desktop.
dancemethis 11mo ago
I kept forgetting Narrator is a Windows program, and the post read like the author was referring to the "Narrator voice in their head" while testing the UIs. It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
ogoffart 11mo ago
Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL. This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperative-for-ui https://slint.dev/blog/domain-specific-language-vs-imperativ...
- OtomotO 11mo ago
  I'd like to have non-imperative gui code in Rust. Why Rust? Because I like its power and with recent developments such as subsecond the compile times are absolutely negligible.
- vinceguidry 11mo ago
  When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion. Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did. My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide. I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.
lenkite 11mo ago
Doesn't https://github.com/longbridge/gpui-component https://github.com/longbridge/gpui-component tick all your boxes ?
- Narishma 11mo ago
  Does it work without a modern GPU?
  - lenkite 11mo ago
    Seriously, there is requirement to CPU draw UI components too ? OP didn't say that and it sounds crazy anyways. Even your point-of-sale terminal units with displays have integrated GPUs. Popular Ex in 2025: Qualcomm Snapdragon 810 SoC (octa-core ARM) with Adreno 430 GPU.
    - Narishma 11mo ago
      I mean if it requires a modern GPU, that leaves a ton of perfectly working older hardware out in the dust, even those with a GPU if they don't support modern APIs. That's a huge downside when the competing toolkits run just fine on the CPU.
sunbum 11mo ago
Why does that link redirect to a fart sound hosted on Wikipedia?
- heavensteeth 11mo ago
  The author doesn't like HN.
  - dmit 11mo ago
    The Referer header strikes again. You'd think the typo in its name would be the worst thing about it, but nope.
  - dspillett 11mo ago
    This is sort of thing is why I have a “they don't want me there, and I'm fine with that” list in my PiHole config.
- bakugo 11mo ago
  A quick glance at the website in question suggests that its owner may not be particularly mentally mature.
- GaggiX 11mo ago
  I find it always hilarious when websites check the referer for HN and do some random shit. "Alive internet theory"
- SpikedCola 11mo ago
  // Vidrun, born of the sea-wind through the spruce // Vidrun, green-tinged offshoot of my bough, joy and burden of my life // Vidrun, fierce and clever, may our clanâ€™s wisdom be yours: // // Never read Hacker News // - Aphyr, "Hexing the technical interview" if (document.referrer.startsWith("https://news.ycombinator.com")) { document.location = "https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav" } > https://www.boringcactus.com/assets/site.js https://www.boringcactus.com/assets/site.js
elmt35 11mo ago
Zed (https://zed.dev https://zed.dev) is a GUI built in rust. Im not an expert in GUI building so maybe I'm wrong and they used a separate language for the GUI.
- stefanka 11mo ago
  They use rust for the gpu https://github.com/zed-industries/zed/tree/main/crates/gpui https://github.com/zed-industries/zed/tree/main/crates/gpui See the discussion on a collection of elements ontop https://news.ycombinator.com/item?id=45719004 https://news.ycombinator.com/item?id=45719004
- adastra22 11mo ago
  They use Rust, but they basically reinvented the wheel for everything they did, because the existing GUI stuff in the rust ecosystem sucked so badly it wasn't worth fixing. Which is great, Zed's stack is pretty damn good. But like anything not yet widely used outside of its original use case, it can be rough around the edges, and just plain doesn't support anything that is not needed by Zed.
  - deleted 11mo ago
    [deleted]
  - IshKebab 11mo ago
    Yeah and even then they have a ton of rendering and performance issues. GUI frameworks are just incredibly hard to do right, and take a ton of time. I'm betting on Slint. I kind of hated QML but it looks like they have learned a lot of lessons.
    - bayesnet 11mo ago
      I evaluated gpui for a project I’m working on. While I’ve found the rendering and performance to be great (and actually switched to Zed as my daily driver after playing with it), the (absence of an) accessibility story made me grudgingly just use tauri. I really want to love gpui and would like to avoid using webviews, the advantage of web-based apps is that accessibility is (relatively) easy to do if you’re attentive to it. At the time I looked at it, gpui did not support screen readers etc at all. I suppose I understand why they made that decision given their business priorities, but it’s hard for me to tell my vision-impaired friends and colleagues that there’s literally no way for them to use my app.
weinzierl 11mo ago
Apart from what you said about the GUI situation in Rust (which I disagree with) I think TUI's have their niche. I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability. This is why people often resort to command line tools, rightfully so. There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.
- Jaxan 11mo ago
  > In addition they cause other difficulties, like testability, i18n, l10n and accessability. Most TUIs don’t have these either. So I don’t see this as a difference between TUI/GUI. If you want to make a GUI and want to ignore these things, you are free to do so.
  - dale_glass 11mo ago
    Where I think TUIs had a niche GUIs don't quite reproduce is in the very particular way DOS TUIs processed input. An old school DOS TUI reads keyboard input one character at a time from a buffer, doesn't clear the buffer in between screens, and is ideally laid out such that a good part of the input is guaranteed to be fixed for a given operation. They also were built without mouse usage. So an operator can hammer out a sequence like "ArrowDown, ArrowDown, ENTER, Y, ENTER, John Smith, ENTER" and even if the system is too slow to keep up with the input, it still works perfectly. Modern GUIs almost never make this work near as well. You need to reach for the mouse, input during delays gets lost, the UI may not be perfectly predictable, sometimes the UI may even shift around while things are loading. Then also neither does Linux, I find that the user experience on DOS was far better than with ncurses apps that have all kinds of weirdness.
- miki123211 11mo ago
  To be fair, TUIs are strictly worse accessibility-wise than GUIs. There's no standard to communicate TUI semantics to assistive technology, and whatever few standards actually exist (like using the cursor to navigate menus instead of some custom highlight) aren't followed. With GUIs, those standards exist, and are at least somewhat implemented by all major (non-Rust)UI frameworks.
Tepix 11mo ago
"Maybe one day an AI bro who pays for Twitter will contribute something positive to society, but this is not that day." Haha!
linhns 11mo ago
Given Qt consists of hardcore lovers of old C++, this is unlikely to happen in this generation.
- Kelteseth 11mo ago
  They literally announced that they are working on it: https://www.qt.io/qt-bridges https://www.qt.io/qt-bridges
  - andrewl-hn 11mo ago
    There's already a very good bridge for Qt: https://kdab.github.io/cxx-qt/book/ https://kdab.github.io/cxx-qt/book/ In the linked article the author had trouble building Qt for windows and because they wanted to go through 40+ GUI libraries they skipped it instead of pushing through. That's why it doesn't show up in final short-list of good options. In my books (writing Rust since 2013, but haven't done any GUI work in it), Qt and Slint are the best options out there.
kibwen 11mo ago
No, the people making TUIs in Rust are making TUIs because they love TUIs, and because Ratatui is pretty delightful. The state of GUI frameworks in Rust is irrelevant for this purpose, because even if there existed your ideal of Qt in Rust (putting aside the debatable notion that Qt is some sort of pinnacle of design), the people making TUIs wouldn't care, because that's not what they want to make.
- hombre_fatal 11mo ago
  Also once your workflow is increasingly keyboard based (like when using a tiled window manager), TUIs just make more sense. Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
  - jnovek 11mo ago
    I think my low-key long-term goal is to eventually fully eliminate the mouse while still enjoying the niceties of a modern GUI desktop.
    - Zetaphor 11mo ago
      Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.
  - WD-42 11mo ago
    Other benefits: 1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size. 2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord). 3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely. 4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously. 5. Did I mention they are fun to use and relatively easy to develop?
speed_spread 11mo ago
I think it's pretty normal to have a language dedicated to the UI structure. It should be declarative for easy machine manipulation with a WYSIWYG editor and could be translated to code before compilation. My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.
PoorRustDev 11mo ago
"GUI situation in Rust is dreadful" I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used. Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."
- IshKebab 11mo ago
  I strongly disagree with this. Obviously Rust hasn't had the decades of life that C/C++ has to give you weird niche libraries, but at this point the Rust crate ecosystem is huge and you have to go fairly niche before you find something where there simply isn't a Rust option. Usually you find something and it's a lot nicer than the C option. GUI is kind of unique because it's a really hard problem - both a ton of work and also a bit awkward to make ergonomic in Rust. > last updated 1-3 years ago That's way too low a bar. I bet most of these niche C libraries that don't have Rust equivalents are similarly slow-moving. GNU Make regularly goes 4 years without a release but it's still alive.
  - the__alchemist 11mo ago
    This is surprising to hear; my experience matches the parent comments' exactly. The crates exist, but are usually toys that haven't been applied to practical problem. This is a generalization, but it applies well in many domains. Often, they're someone's one-off school project, a "let's build X in rust" from someone who doesn't have a practical use case for X etc.
- the__alchemist 11mo ago
claudiug 11mo ago
there is this new library: https://longbridge.github.io/gpui-component/ https://longbridge.github.io/gpui-component/
athoneycutt 11mo ago
What about Iced or libcosmic (based on Iced)?
WD-42 11mo ago
The linked post is worthless. It’s a bunch of whining about how various rust stuff doesn’t work correctly on Windows “The most popular OS for developers.” Nobody cares.
the__alchemist 11mo ago
It's amusing reading things like this. Meanwhile, we have at least 4 high-quality, practical GUI frameworks to choose from. You want QT in rust? I get that, but that is different from your claim about the state of GUIs in rust. "I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B". I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today! I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!
dlivingston 11mo ago
IMO, traditional GUI frameworks in Rust (like Qt) are difficult for the same reason that game engines in Rust are difficult: cyclical references. A window might contain a group box which contains a text field and a button. All of these are (direct or indirect) children of the window, but all children also hold a reference to their parent. Qt's signal-slot mechanism would also be difficult to implement in Rust.
- k_bx 11mo ago
  Why not just use Arc and clone the cyclical references as much as you want `button: RefCell<Option<Arc<Button>>>`?
vablings 11mo ago
I just completely disagree. We have Slint, Dioxus, Tauri, Egui (best imo). If Dioxus blitz renderer takes off them it will vastly better than 99% of options for other languages
junon 11mo ago
> Rust is simply not meant for GUI-based data design It's no less or more equipped than C or C++, so not really sure what to make of this comment given the username lol.
krzyk 11mo ago
> People keep asking why TUIs in Rust Because it is quite easy to do. There are also TUIs in other languages, just Rust is more cool.
k_bx 11mo ago
Cosmic DE is written in Rust, it's nice and is a good proof you can do GUI in Rust quite well
Diti 11mo ago
Wrong link? My browser (Firefox on iOS) redirects me to a fart sound media [1], and going back in history takes me back to here. [1]: https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fa...

goku12 11mo ago

You basically preempted nearly every single option, including an incumbent one. I don't believe it's fair to judge Rust based on its compatibility with Qt alone - something written in C++. Nothing against C++, but it's harder to get C++ and Rust to work together. You haven't addressed Iced yet, though going by your requirements, you're unlikely to be satisfied by it as well. Iced is not there yet, but it is the native GUI toolkit of the Cosmic desktop.

dancemethis 11mo ago

I kept forgetting Narrator is a Windows program, and the post read like the author was referring to the "Narrator voice in their head" while testing the UIs. It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.

ogoffart 11mo ago

Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL. This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperative-for-ui https://slint.dev/blog/domain-specific-language-vs-imperativ...

OtomotO 11mo ago
I'd like to have non-imperative gui code in Rust. Why Rust? Because I like its power and with recent developments such as subsecond the compile times are absolutely negligible.
vinceguidry 11mo ago
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion. Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did. My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide. I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.

lenkite 11mo ago

Doesn't https://github.com/longbridge/gpui-component https://github.com/longbridge/gpui-component tick all your boxes ?

Narishma 11mo ago
Does it work without a modern GPU?
- lenkite 11mo ago
  Seriously, there is requirement to CPU draw UI components too ? OP didn't say that and it sounds crazy anyways. Even your point-of-sale terminal units with displays have integrated GPUs. Popular Ex in 2025: Qualcomm Snapdragon 810 SoC (octa-core ARM) with Adreno 430 GPU.
  - Narishma 11mo ago
    I mean if it requires a modern GPU, that leaves a ton of perfectly working older hardware out in the dust, even those with a GPU if they don't support modern APIs. That's a huge downside when the competing toolkits run just fine on the CPU.

sunbum 11mo ago

Why does that link redirect to a fart sound hosted on Wikipedia?

heavensteeth 11mo ago
The author doesn't like HN.
- dmit 11mo ago
  The Referer header strikes again. You'd think the typo in its name would be the worst thing about it, but nope.
- dspillett 11mo ago
  This is sort of thing is why I have a “they don't want me there, and I'm fine with that” list in my PiHole config.
bakugo 11mo ago
A quick glance at the website in question suggests that its owner may not be particularly mentally mature.
GaggiX 11mo ago
I find it always hilarious when websites check the referer for HN and do some random shit. "Alive internet theory"
SpikedCola 11mo ago
// Vidrun, born of the sea-wind through the spruce // Vidrun, green-tinged offshoot of my bough, joy and burden of my life // Vidrun, fierce and clever, may our clanâ€™s wisdom be yours: // // Never read Hacker News // - Aphyr, "Hexing the technical interview" if (document.referrer.startsWith("https://news.ycombinator.com")) { document.location = "https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav" } > https://www.boringcactus.com/assets/site.js https://www.boringcactus.com/assets/site.js

elmt35 11mo ago

Zed (https://zed.dev https://zed.dev) is a GUI built in rust. Im not an expert in GUI building so maybe I'm wrong and they used a separate language for the GUI.

stefanka 11mo ago
They use rust for the gpu https://github.com/zed-industries/zed/tree/main/crates/gpui https://github.com/zed-industries/zed/tree/main/crates/gpui See the discussion on a collection of elements ontop https://news.ycombinator.com/item?id=45719004 https://news.ycombinator.com/item?id=45719004
adastra22 11mo ago
They use Rust, but they basically reinvented the wheel for everything they did, because the existing GUI stuff in the rust ecosystem sucked so badly it wasn't worth fixing. Which is great, Zed's stack is pretty damn good. But like anything not yet widely used outside of its original use case, it can be rough around the edges, and just plain doesn't support anything that is not needed by Zed.
- deleted 11mo ago
  [deleted]
- IshKebab 11mo ago
  Yeah and even then they have a ton of rendering and performance issues. GUI frameworks are just incredibly hard to do right, and take a ton of time. I'm betting on Slint. I kind of hated QML but it looks like they have learned a lot of lessons.
  - bayesnet 11mo ago
    I evaluated gpui for a project I’m working on. While I’ve found the rendering and performance to be great (and actually switched to Zed as my daily driver after playing with it), the (absence of an) accessibility story made me grudgingly just use tauri. I really want to love gpui and would like to avoid using webviews, the advantage of web-based apps is that accessibility is (relatively) easy to do if you’re attentive to it. At the time I looked at it, gpui did not support screen readers etc at all. I suppose I understand why they made that decision given their business priorities, but it’s hard for me to tell my vision-impaired friends and colleagues that there’s literally no way for them to use my app.

weinzierl 11mo ago

Apart from what you said about the GUI situation in Rust (which I disagree with) I think TUI's have their niche. I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability. This is why people often resort to command line tools, rightfully so. There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.

Jaxan 11mo ago
> In addition they cause other difficulties, like testability, i18n, l10n and accessability. Most TUIs don’t have these either. So I don’t see this as a difference between TUI/GUI. If you want to make a GUI and want to ignore these things, you are free to do so.
- dale_glass 11mo ago
  Where I think TUIs had a niche GUIs don't quite reproduce is in the very particular way DOS TUIs processed input. An old school DOS TUI reads keyboard input one character at a time from a buffer, doesn't clear the buffer in between screens, and is ideally laid out such that a good part of the input is guaranteed to be fixed for a given operation. They also were built without mouse usage. So an operator can hammer out a sequence like "ArrowDown, ArrowDown, ENTER, Y, ENTER, John Smith, ENTER" and even if the system is too slow to keep up with the input, it still works perfectly. Modern GUIs almost never make this work near as well. You need to reach for the mouse, input during delays gets lost, the UI may not be perfectly predictable, sometimes the UI may even shift around while things are loading. Then also neither does Linux, I find that the user experience on DOS was far better than with ncurses apps that have all kinds of weirdness.
miki123211 11mo ago
To be fair, TUIs are strictly worse accessibility-wise than GUIs. There's no standard to communicate TUI semantics to assistive technology, and whatever few standards actually exist (like using the cursor to navigate menus instead of some custom highlight) aren't followed. With GUIs, those standards exist, and are at least somewhat implemented by all major (non-Rust)UI frameworks.

Tepix 11mo ago

"Maybe one day an AI bro who pays for Twitter will contribute something positive to society, but this is not that day." Haha!

linhns 11mo ago

Given Qt consists of hardcore lovers of old C++, this is unlikely to happen in this generation.

Kelteseth 11mo ago
They literally announced that they are working on it: https://www.qt.io/qt-bridges https://www.qt.io/qt-bridges
- andrewl-hn 11mo ago
  There's already a very good bridge for Qt: https://kdab.github.io/cxx-qt/book/ https://kdab.github.io/cxx-qt/book/ In the linked article the author had trouble building Qt for windows and because they wanted to go through 40+ GUI libraries they skipped it instead of pushing through. That's why it doesn't show up in final short-list of good options. In my books (writing Rust since 2013, but haven't done any GUI work in it), Qt and Slint are the best options out there.

kibwen 11mo ago

No, the people making TUIs in Rust are making TUIs because they love TUIs, and because Ratatui is pretty delightful. The state of GUI frameworks in Rust is irrelevant for this purpose, because even if there existed your ideal of Qt in Rust (putting aside the debatable notion that Qt is some sort of pinnacle of design), the people making TUIs wouldn't care, because that's not what they want to make.

hombre_fatal 11mo ago
Also once your workflow is increasingly keyboard based (like when using a tiled window manager), TUIs just make more sense. Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
- jnovek 11mo ago
  I think my low-key long-term goal is to eventually fully eliminate the mouse while still enjoying the niceties of a modern GUI desktop.
  - Zetaphor 11mo ago
    Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.
- WD-42 11mo ago
  Other benefits: 1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size. 2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord). 3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely. 4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously. 5. Did I mention they are fun to use and relatively easy to develop?

speed_spread 11mo ago

I think it's pretty normal to have a language dedicated to the UI structure. It should be declarative for easy machine manipulation with a WYSIWYG editor and could be translated to code before compilation. My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.

PoorRustDev 11mo ago

"GUI situation in Rust is dreadful" I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used. Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."

IshKebab 11mo ago
I strongly disagree with this. Obviously Rust hasn't had the decades of life that C/C++ has to give you weird niche libraries, but at this point the Rust crate ecosystem is huge and you have to go fairly niche before you find something where there simply isn't a Rust option. Usually you find something and it's a lot nicer than the C option. GUI is kind of unique because it's a really hard problem - both a ton of work and also a bit awkward to make ergonomic in Rust. > last updated 1-3 years ago That's way too low a bar. I bet most of these niche C libraries that don't have Rust equivalents are similarly slow-moving. GNU Make regularly goes 4 years without a release but it's still alive.
- the__alchemist 11mo ago
  This is surprising to hear; my experience matches the parent comments' exactly. The crates exist, but are usually toys that haven't been applied to practical problem. This is a generalization, but it applies well in many domains. Often, they're someone's one-off school project, a "let's build X in rust" from someone who doesn't have a practical use case for X etc.
the__alchemist 11mo ago

claudiug 11mo ago

there is this new library: https://longbridge.github.io/gpui-component/ https://longbridge.github.io/gpui-component/

athoneycutt 11mo ago

What about Iced or libcosmic (based on Iced)?

WD-42 11mo ago

The linked post is worthless. It’s a bunch of whining about how various rust stuff doesn’t work correctly on Windows “The most popular OS for developers.” Nobody cares.

the__alchemist 11mo ago

It's amusing reading things like this. Meanwhile, we have at least 4 high-quality, practical GUI frameworks to choose from. You want QT in rust? I get that, but that is different from your claim about the state of GUIs in rust. "I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B". I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today! I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!

dlivingston 11mo ago

IMO, traditional GUI frameworks in Rust (like Qt) are difficult for the same reason that game engines in Rust are difficult: cyclical references. A window might contain a group box which contains a text field and a button. All of these are (direct or indirect) children of the window, but all children also hold a reference to their parent. Qt's signal-slot mechanism would also be difficult to implement in Rust.

k_bx 11mo ago
Why not just use Arc and clone the cyclical references as much as you want `button: RefCell<Option<Arc<Button>>>`?

vablings 11mo ago

I just completely disagree. We have Slint, Dioxus, Tauri, Egui (best imo). If Dioxus blitz renderer takes off them it will vastly better than 99% of options for other languages

junon 11mo ago

> Rust is simply not meant for GUI-based data design It's no less or more equipped than C or C++, so not really sure what to make of this comment given the username lol.

krzyk 11mo ago

> People keep asking why TUIs in Rust Because it is quite easy to do. There are also TUIs in other languages, just Rust is more cool.

k_bx 11mo ago

Cosmic DE is written in Rust, it's nice and is a good proof you can do GUI in Rust quite well

Diti 11mo ago

Wrong link? My browser (Firefox on iOS) redirects me to a fart sound media [1], and going back in history takes me back to here. [1]: https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fa...