8 ms·

Why is building a UI in Rust so hard?

111 points by osener 4y ago

pvinis 4y ago
the people over at https://zed.dev https://zed.dev have done a great job. do they use something special?
ar9av 4y ago
First of all, it is great that there is are ongoing attempts to build a new approach at creating UI with Rust. I hope it turns out into several competing frameworks with different target audiences. I believe, you are confusing performance with responsiveness. Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time, your approach keeps wasting processor cycles to build widget tree on demand for rendering. This could be unacceptable for devices with an energy budget (IOT, for example). So, your approach works well where loss of efficiency is not critical.
- taneq 4y ago
  Rebuilding your widget hierarchy every frame is overhead, and arguably wasted, but realistically it’s a tiny fraction of your application’s CPU time.
- nemothekid 4y ago
  >Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time Is there a "traditional" UI framework that does this? Most UI frameworks are retained anyways and will build a tree (ex. Qt, Fltk); and will render at 60fps (or throttle is there is nothing to do). As far as overhead goes, I can't imagine the Rust approach being anymore expensive. The approach of just updating and rendering a single widget is hypothetically more performant, but I rarely see it done in the wild due to how complex it can become as your UI gets more complex.
  - int_19h 4y ago
    It was the standard way to do native UI on the desktop before composition became common in mid-00s. I don't recall it being particularly complex in practice, especially when the frameworks abstracted most of it away. E.g. WinForms running on WinXP would still be doing this under the hood, but you as a developer could just set up data binding and write the painting code for any custom widgets (and wouldn't have to care about it getting called at the right time).
BiteCode_dev 4y ago
Building an UI is hard, even with language with good support for it. Web ui are hard. Python ui are hard.
- xony 4y ago
  [dead]
- marton78 4y ago
  I can confirm. I'm regularly surprised how slow my iOS developers are at developing a few screens.
  - illiarian 4y ago
    It's amazing how much we've regressed since Delphi.
    - VBprogrammer 4y ago
      And Visual Basic for all of its faults..
      - Bootvis 4y ago
        I started programming with Visual Basic 6 and still feel robbed that in the 25 years of programming after I never built a native GUI.
        wolpoli 4y ago
        I never fully understood why we couldn't have the VB/Winform model of building GUI on the web. Is it because we need the designer skinnable GUI? With WebAssembly and CSS grid layout, could we finally get a modernize VB/Winform?
        BiteCode_dev 4y ago
        There are plenty of services that offers that. Even MS used to provide that with frontpage. The real answer to your question lies in why people don't use them much.
xony 4y ago
[dead]
recuter 4y ago
This is a white whale for a lot of people. http://www.areweguiyet.com http://www.areweguiyet.com (seems updates to this thing have stopped?) https://blog.logrocket.com/state-of-rust-gui-libraries/ https://blog.logrocket.com/state-of-rust-gui-libraries/ The state of TUI on the other hand is better (posted recently, there are a few others): https://github.com/tui-rs-revival/ratatui https://github.com/tui-rs-revival/ratatui https://news.ycombinator.com/item?id=35173866 https://news.ycombinator.com/item?id=35173866
- jeroenhd 4y ago
  There are many GUI libraries out there that make use of existing toolkits written in other languages. Honestly, I think that may just be the correct way to go. Not only does this allow to use "normal" trees for setting up components, it also reuses most of the usability features. Drawing a box and some text has been solved now. Several Rust libraries can render entire UIs with all the common controls you can think of. The downside of using these pure Rust libraries is that they seem focused more on features than usability. The created UI looks like it belongs inside a video game engine. It doesn't match any of the controls you'd expect to see, it doesn't even try to use your system's theme settings, or even the common OS conventions in some case, especially if you're trying to go cross platform. One of the best ways to develop snappy GUIs that stick to your system's settings and themes is to use the windows crate and package Wine with your executable. Wine can emulate your system's theme quite convincingly and the Windows API solves most of the accessibility problems. It's a massive pain to develop against, but in my opinion the end result is much more convincing as a "real" UI than many of the native libraries. After that, Qt provides some pretty good control libraries but interacting with it from Rust is a little painful as you need to choose between tons of wrappers or dropping Rust's safety mechanisms with unsafe{}. Personally, I'm hoping wxRust gets worked out more, as its still in its early stages by its own admission m. WxWidgets solves my usability problem well enough and is lightweight enough that I think it could finally solve my UI usability quirks. Sure, you'll have the lack of safety guarantees and rely on the C renderer, but WxWidgets has been out for so long that I'm confident the types of bugs switching Rust would solve have mostly been found by now.
- deleted 4y ago
  [deleted]
ttiurani 4y ago
Raph Levien, who's behind Druid and Xilem (https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...) UI frameworks, recently gave a talk about very similar issues. Slides here: https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaKag-vtXmVD8nUBD7Ym-pfwJM/edit?usp=sharing https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaK...
- cloogshicer 4y ago
  The first link especially is super insightful, thanks!
- rayiner 4y ago
  Thanks for sharing this! Especially for linking the slides and not just the video.
paulsutter 4y ago
English is the new UI
- amelius 4y ago
  Yes, with AI getting so good we'll soon don't need to look at screens to get stuff done. We'll just ask the AI.
2muchcoffeeman 4y ago
Why not have a separate language for UI that calls native rust apis?
- larnon 4y ago
  I believe that is what Tauri is for.
linhns 4y ago
Because building an UI is hard?
dgb23 4y ago
I haven't done any UI work in Rust, have used the language sparingly on the side. But while reading the article, I was thinking "You're modelling the tree wrong! The memory layout doesn't need to know that it is a tree!" - gladly we came to the same conclusion. The funny thing with this pattern is that Rust is much more loose when it comes to modelling with hashmaps and vectors. You are essentially creating user-space references and maintaining them with your own logic. You're basically circumventing the borrow checker, but also a lot of other problems as you encapsulate the maintenance of these references within your tree / graph data structure. But in a sense it's cheating! When you give me a key to a hashmap, do _I_ know whether the thing is there?
- MrLeap 4y ago
  I'm not a rust developer, but I see all the signs and scents of somebody who detects the truncheon and the trap. My guess is that you're adrift in a continuum made by somebody else who started with one goal, but found an ancillary surprise benefit worthy of persisting under the umbrella of the previous illusion. Bricks kept getting put down, the pamphlet never changed, then bam there you are. I wager you're right in the mix before former turned to latter.
  - bschwindHN 4y ago
    Sorry, I read your comment twice but I have no idea what you're trying to say.
    - satoshiiii 4y ago
      Me too so I asked ChatGPT to rewrite his comment like a high school student would write : ChatGPT: I'm not a rust developer, but it seems like you know what you're talking about when it comes to detecting problems and traps. My guess is that you're stuck in a situation that someone else created. They started with one goal, but found another good thing that they wanted to keep doing. They kept building and never changed their plan, and now you're stuck in the middle of it. I think you were there before things started to get weird.
  - 4y ago
taneq 4y ago
Is the challenge really Rust’s design? Or is it an ongoing case of best is the enemy of good? It seems like every UI toolkit we see is another attempt at The Perfect UI Paradigm instead of just being Rust bindings for fltk or whatever. (Oh hey that’s a thing! https://www.fltk.org/articles.php?L1771 https://www.fltk.org/articles.php?L1771 )
MrPatan 4y ago
Maybe it turns out web and electron UIs took over the world because web technologies are just a better way of building UIs, and everybody who tries them in earnest realizes it. How about "Every GUI toolkit out there trying to avoid using web tech is going to end up implementing a half-baked implementation of CSS", to coin a phrase.
- dexwiz 4y ago
  Or no toolkit has more engineering hours as the web toolkit put in. Even with its warts, it has so many more features and tools.
- recuter 4y ago
  Somebody should just sponsor a minimal browser engine written in Rust. Bet it would be uniquely well suited for it. Wait..
- BiteCode_dev 4y ago
  Web UI are amazing to build for, and having the browser for free is fantastic, but if a dev manage to get the essential features without web tech, the end result is usually better. It's most of the time snappier and better integrated. The problem is it's not guarantee, and it's way more expensive and hard. Hence electron being so popular.
- ohgodplsno 4y ago
  They are an easier way of building UIs. Better is an opinion. Look at the sheer amount of libraries available for the web made to abstract the dreadful task of maintaining the DOM for you. Additionally, UI work on the web is pretty much only CSS. React doesn't handle drawing elements, it delegates it to the browser. React is the easy part of drawing UIs. You could also make a fancy DSL in Rust for Qt and say "look how bad the web is my UI runs 50 times faster clearly Rust is better at rendering UIs", but we both know that's a lie. Also, CSS is an awful wart and alternatives that have popped up like Compose's Modifier system and CompositionLocals are infinitely better.
  - int_19h 4y ago
BiteCode_dev 4y ago
Great articles, which lead me to check out warps, which looks like a product I would use and consider paying for the pro features. Kudos
pjmlp 4y ago
Recommended reading for everyone that doesn't get how traits are just yet another kind of OOP. "Component Software: Beyond Object-Oriented Programming" https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720 https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720 "Authoring ActiveX with VB 6" https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa262304(v=vs.60) https://learn.microsoft.com/en-us/previous-versions/visualst... "Traits - Composable Units of Behavior" https://scg.unibe.ch/research/traits https://scg.unibe.ch/research/traits "Working with Protocols" https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html https://developer.apple.com/library/archive/documentation/Co...
- andrekandre 4y ago
  to that point, traits themselves originated first in smalltalk correct??
  - pjmlp 4y ago
    Not originally, but they were added after Smalltalk-80, one of the links above has the related paper. They exist now in Squeak and Pharo, both originally based on Xerox's Smalltalk-80 image.
    - c-cube 4y ago
      That's quite weird. These traits don't look like rust's traits, which really are a port of typeclasses from Haskell. I think the section about scala illustrates this well because scala's "traits" are an OO construct, but now scala 3 also" has typeclasses. So... Rust still isn't OO.
      - pjmlp 4y ago
        Ah, trying to go down that route? ECOOP 2009 proceedings paper from a certain Simon Peyton Jones. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://link.springer.com/chapter/10.1007/978-3-642-03013-0_1 https://link.springer.com/chapter/10.1007/978-3-642-03013-0_...
tannhaeuser 4y ago
Rust sucks for UI, async services, language runtimes, and a couple other things because memory usage patterns of those apps don't favor Rust's memory/safety model? I mean, who would've thought? Rust was introduced as a "systems" programming language after all, and doesn't have to be everything to everybody. Rust isn't even extensively used within its originating project/org (FF/Moz). IMHO, Rust's anti-C/C++ narrative also starts from wrong assumptions: in traditional Unix, what you're doing with C (apart from the OS) is implement the runtime of higher-level languages, but no-one has bothered to implement JavaScript or other engine with GC (let alone JIT) because committing to Rust's one-size-fits-all borrow checker just means the result can't be competitive. malloc()/free() also sucks, but its problems are only amplified by today's desire for single-process multithreaded or async backends; for one-shot commandline apps or process-per-request backends OTOH, there hasn't been much of a problem.
- 0atman 4y ago
  Rust's 'one-size-fits-all' approach and the 'rewrite it in rust' movement are due to the language's high-level flexibility whilst also being as low-level as C. If you set out to write a new language in Rust, to escape the perceived limitations of the language, you end up extending Rust, not building a new language, and now you have Rust without the limitation you started with, and others can benefit from your work. I've written two videos on the topic that I'd love to know your thoughts on, the first talking about Rust's universality due to both the unsafe and macro systems: https://www.youtube.com/watch?v=PuMXWc0xrK0&list=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP&index=3 https://www.youtube.com/watch?v=PuMXWc0xrK0&list=PLZaoyhMXgB... The second a deeper dive into the macro system: https://www.youtube.com/watch?v=MWRPYBoCEaY&list=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP&index=16 https://www.youtube.com/watch?v=MWRPYBoCEaY&list=PLZaoyhMXgB...
classified 4y ago
Whoever designed the color scheme for that page has to be blind. But yeah, Rust's borrow checker is not designed for GUI apps.
satvikpendem 4y ago
I gave up and started using Flutter with flutter_rust_bridge for business logic. I'm convinced that UI development from scratch simply cannot happen without a large company backing the project, giving it time and money. Flutter took over ten years and likely millions of dollars. HTML, CSS, and JS / TS? Likely billions. This is because simply building the UI toolkit itself is usually not a prime motivator for a startup, they want to work on their differentiating features, not on reinventing the wheel. Of course, if the startup is a text editor or other such UI heavy app, then it may make sense to reinvent the UI wheel. Figma showed this successfully, and perhaps Zed and Warp might, too.
- pas 4y ago
  Oh, flutter + rust seems like a great combo. (Because Flutter seems great for UI work, but Dart is very meh for everything else.) Have you tried Tauri or some other Electron-like alternative by any chance? How do you like Flutter+Rust so far, and what's your "baseline"? :)
  - beckler 4y ago
    I too am interested in the flutter aspect, but I just recently worked with Tauri as part of a rewrite project and it was a decent experience. There are still some rough edges and small gaps, but overall it’s pretty well done. Plus, when you’re ready to ship your app, they give you tools that make packaging and code-signing very easy. I would recommend it if you have any interest in it. Compare this to my experience with iced, where I discovered that I love the elm architecture, but dealing with the UI parts became exponentially more complex the larger it grew, so many undocumented or under documented components, plus upgrading between minor versions would cause breaking changes that weren’t always easy to solve because of the lack of documentation or examples.
  - satvikpendem 4y ago
    I like Flutter and Rust, it's pretty nice. I actually like Dart as well, it has some very interesting features. I've used Electron and Tauri a bit before but I didn't like that it still wasn't "native," it still used a web wrapper.
jasmer 4y ago
UIs are inherently about state, and a lot of state is hard in Rust. The big 'tree of state' is just awkward. UIs are inherently async and event drive, it's callbacks over callbacks, again, harder in rust. UIs have a lot of detail. A little screen has a lot of hidden bit of small complexity. Rust is a heavy language that wants to treat every line of code as an existential security threat and performance. It's really not the right tool.
smodo 4y ago
Interesting that they are working with one of the Zed people. I’ve been wondering about the Ui framework they use. Opening up this framework could invite a lot of attention since they are dogfooding it in a (imho) solid product.
foldr 4y ago
As a relatively old person, I've had a few experiences of waiting for my favorite niche language to finally get a decent GUI library. In my experience, it never happens. It's just too much work. Only the most popular few programming languages in any given moment have usable GUI options. Even something as comparatively mainstream as Go lacks a good GUI story.
noelwelsh 4y ago
I'm confused by the discussion of OO. Just use an enum, aka algebraic data type, if you want control over the data. You can build an extension point into the ADT for user defined components, if that is desirable. The tradeoffs of OO style vs FP style vs having-your-cake-and-eating-it aka the expression problem are well studied. (This comment is a bit cryptic. Sorry. Don't have much time right now. Might return later.) My experience using ECS in bevy is it feels like fancy spaghetti code. I'm not convinced it's a great approach, at least on the small scale I'm working at.
- cloogshicer 4y ago
  Please do return later and elaborate on what you mean by having-your-cake-and-eating-it aka the expression problem. I'm super interested in this stuff and would like to hear more.
  - mjburgess 4y ago
    The expression problem is, roughly, how easy it is to extend a program without recompiling it. OO is typically regarded as making it easier to extend the data types of a program, since you can introduce new ones by inheritance at any time. Whereas pure FP systems specify types exhaustively at definition. FP typically makes it easier to extend the functions, since you can define arbitary more functions on the "public" type system; whereas OO encapsulates stuff and makes it harder to do that. > You can build an extension point into the ADT for user defined components I assume that means there are ways of making the pure-FP approach OO-like, and vice versa. I think its nevertheless to speak about affordances here, and rust is in my view, one of the poorest DX/affordancey languages --- the syntax and semantics conspire to create lots of friction. This friction isnt really considered in "the expression problem", but i think is very important in practice. We should have a "frictionless expression problem" and I think that's the issue with rust: it doesnt frictionalessly extend in the ways needed by UI programming.
    - cloogshicer 4y ago
      Thank you for taking the time to explain!
rvz 4y ago
Perhaps the most obvious answer is that it is may not be the appropriate language for that use case? It is like suggesting to use Solidity or Assembly to build the UI for your app.
ummonk 4y ago
ECS essentially uses the relational-database-like data storage. To model a tree, ideally you would have ECS but with graph-database-like data storage.

111 points by osener 4y ago

the people over at https://zed.dev https://zed.dev have done a great job. do they use something special?

First of all, it is great that there is are ongoing attempts to build a new approach at creating UI with Rust. I hope it turns out into several competing frameworks with different target audiences. I believe, you are confusing performance with responsiveness. Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time, your approach keeps wasting processor cycles to build widget tree on demand for rendering. This could be unacceptable for devices with an energy budget (IOT, for example). So, your approach works well where loss of efficiency is not critical.

taneq 4y ago
Rebuilding your widget hierarchy every frame is overhead, and arguably wasted, but realistically it’s a tiny fraction of your application’s CPU time.
nemothekid 4y ago
>Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time Is there a "traditional" UI framework that does this? Most UI frameworks are retained anyways and will build a tree (ex. Qt, Fltk); and will render at 60fps (or throttle is there is nothing to do). As far as overhead goes, I can't imagine the Rust approach being anymore expensive. The approach of just updating and rendering a single widget is hypothetically more performant, but I rarely see it done in the wild due to how complex it can become as your UI gets more complex.
- int_19h 4y ago
  It was the standard way to do native UI on the desktop before composition became common in mid-00s. I don't recall it being particularly complex in practice, especially when the frameworks abstracted most of it away. E.g. WinForms running on WinXP would still be doing this under the hood, but you as a developer could just set up data binding and write the painting code for any custom widgets (and wouldn't have to care about it getting called at the right time).

BiteCode_dev 4y ago

Building an UI is hard, even with language with good support for it. Web ui are hard. Python ui are hard.

xony 4y ago
[dead]
marton78 4y ago
I can confirm. I'm regularly surprised how slow my iOS developers are at developing a few screens.
- illiarian 4y ago
  It's amazing how much we've regressed since Delphi.
  - VBprogrammer 4y ago
    And Visual Basic for all of its faults..
    - Bootvis 4y ago
      I started programming with Visual Basic 6 and still feel robbed that in the 25 years of programming after I never built a native GUI.
      - wolpoli 4y ago
        I never fully understood why we couldn't have the VB/Winform model of building GUI on the web. Is it because we need the designer skinnable GUI? With WebAssembly and CSS grid layout, could we finally get a modernize VB/Winform?
        BiteCode_dev 4y ago
        There are plenty of services that offers that. Even MS used to provide that with frontpage. The real answer to your question lies in why people don't use them much.

xony 4y ago

[dead]

recuter 4y ago

This is a white whale for a lot of people. http://www.areweguiyet.com http://www.areweguiyet.com (seems updates to this thing have stopped?) https://blog.logrocket.com/state-of-rust-gui-libraries/ https://blog.logrocket.com/state-of-rust-gui-libraries/ The state of TUI on the other hand is better (posted recently, there are a few others): https://github.com/tui-rs-revival/ratatui https://github.com/tui-rs-revival/ratatui https://news.ycombinator.com/item?id=35173866 https://news.ycombinator.com/item?id=35173866

jeroenhd 4y ago
There are many GUI libraries out there that make use of existing toolkits written in other languages. Honestly, I think that may just be the correct way to go. Not only does this allow to use "normal" trees for setting up components, it also reuses most of the usability features. Drawing a box and some text has been solved now. Several Rust libraries can render entire UIs with all the common controls you can think of. The downside of using these pure Rust libraries is that they seem focused more on features than usability. The created UI looks like it belongs inside a video game engine. It doesn't match any of the controls you'd expect to see, it doesn't even try to use your system's theme settings, or even the common OS conventions in some case, especially if you're trying to go cross platform. One of the best ways to develop snappy GUIs that stick to your system's settings and themes is to use the windows crate and package Wine with your executable. Wine can emulate your system's theme quite convincingly and the Windows API solves most of the accessibility problems. It's a massive pain to develop against, but in my opinion the end result is much more convincing as a "real" UI than many of the native libraries. After that, Qt provides some pretty good control libraries but interacting with it from Rust is a little painful as you need to choose between tons of wrappers or dropping Rust's safety mechanisms with unsafe{}. Personally, I'm hoping wxRust gets worked out more, as its still in its early stages by its own admission m. WxWidgets solves my usability problem well enough and is lightweight enough that I think it could finally solve my UI usability quirks. Sure, you'll have the lack of safety guarantees and rely on the C renderer, but WxWidgets has been out for so long that I'm confident the types of bugs switching Rust would solve have mostly been found by now.
deleted 4y ago
[deleted]

ttiurani 4y ago

Raph Levien, who's behind Druid and Xilem (https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...) UI frameworks, recently gave a talk about very similar issues. Slides here: https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaKag-vtXmVD8nUBD7Ym-pfwJM/edit?usp=sharing https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaK...

cloogshicer 4y ago
The first link especially is super insightful, thanks!
rayiner 4y ago
Thanks for sharing this! Especially for linking the slides and not just the video.

paulsutter 4y ago

English is the new UI

amelius 4y ago
Yes, with AI getting so good we'll soon don't need to look at screens to get stuff done. We'll just ask the AI.

2muchcoffeeman 4y ago

Why not have a separate language for UI that calls native rust apis?

larnon 4y ago
I believe that is what Tauri is for.

linhns 4y ago

Because building an UI is hard?

dgb23 4y ago

I haven't done any UI work in Rust, have used the language sparingly on the side. But while reading the article, I was thinking "You're modelling the tree wrong! The memory layout doesn't need to know that it is a tree!" - gladly we came to the same conclusion. The funny thing with this pattern is that Rust is much more loose when it comes to modelling with hashmaps and vectors. You are essentially creating user-space references and maintaining them with your own logic. You're basically circumventing the borrow checker, but also a lot of other problems as you encapsulate the maintenance of these references within your tree / graph data structure. But in a sense it's cheating! When you give me a key to a hashmap, do _I_ know whether the thing is there?

MrLeap 4y ago
I'm not a rust developer, but I see all the signs and scents of somebody who detects the truncheon and the trap. My guess is that you're adrift in a continuum made by somebody else who started with one goal, but found an ancillary surprise benefit worthy of persisting under the umbrella of the previous illusion. Bricks kept getting put down, the pamphlet never changed, then bam there you are. I wager you're right in the mix before former turned to latter.
- bschwindHN 4y ago
  Sorry, I read your comment twice but I have no idea what you're trying to say.
  - satoshiiii 4y ago
    Me too so I asked ChatGPT to rewrite his comment like a high school student would write : ChatGPT: I'm not a rust developer, but it seems like you know what you're talking about when it comes to detecting problems and traps. My guess is that you're stuck in a situation that someone else created. They started with one goal, but found another good thing that they wanted to keep doing. They kept building and never changed their plan, and now you're stuck in the middle of it. I think you were there before things started to get weird.
- 4y ago

taneq 4y ago

Is the challenge really Rust’s design? Or is it an ongoing case of best is the enemy of good? It seems like every UI toolkit we see is another attempt at The Perfect UI Paradigm instead of just being Rust bindings for fltk or whatever. (Oh hey that’s a thing! https://www.fltk.org/articles.php?L1771 https://www.fltk.org/articles.php?L1771 )

MrPatan 4y ago

Maybe it turns out web and electron UIs took over the world because web technologies are just a better way of building UIs, and everybody who tries them in earnest realizes it. How about "Every GUI toolkit out there trying to avoid using web tech is going to end up implementing a half-baked implementation of CSS", to coin a phrase.

dexwiz 4y ago
Or no toolkit has more engineering hours as the web toolkit put in. Even with its warts, it has so many more features and tools.
recuter 4y ago
Somebody should just sponsor a minimal browser engine written in Rust. Bet it would be uniquely well suited for it. Wait..
BiteCode_dev 4y ago
Web UI are amazing to build for, and having the browser for free is fantastic, but if a dev manage to get the essential features without web tech, the end result is usually better. It's most of the time snappier and better integrated. The problem is it's not guarantee, and it's way more expensive and hard. Hence electron being so popular.
ohgodplsno 4y ago
They are an easier way of building UIs. Better is an opinion. Look at the sheer amount of libraries available for the web made to abstract the dreadful task of maintaining the DOM for you. Additionally, UI work on the web is pretty much only CSS. React doesn't handle drawing elements, it delegates it to the browser. React is the easy part of drawing UIs. You could also make a fancy DSL in Rust for Qt and say "look how bad the web is my UI runs 50 times faster clearly Rust is better at rendering UIs", but we both know that's a lie. Also, CSS is an awful wart and alternatives that have popped up like Compose's Modifier system and CompositionLocals are infinitely better.
- int_19h 4y ago

BiteCode_dev 4y ago

Great articles, which lead me to check out warps, which looks like a product I would use and consider paying for the pro features. Kudos

pjmlp 4y ago

Recommended reading for everyone that doesn't get how traits are just yet another kind of OOP. "Component Software: Beyond Object-Oriented Programming" https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720 https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720 "Authoring ActiveX with VB 6" https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa262304(v=vs.60) https://learn.microsoft.com/en-us/previous-versions/visualst... "Traits - Composable Units of Behavior" https://scg.unibe.ch/research/traits https://scg.unibe.ch/research/traits "Working with Protocols" https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html https://developer.apple.com/library/archive/documentation/Co...

andrekandre 4y ago
to that point, traits themselves originated first in smalltalk correct??
- pjmlp 4y ago
  Not originally, but they were added after Smalltalk-80, one of the links above has the related paper. They exist now in Squeak and Pharo, both originally based on Xerox's Smalltalk-80 image.
  - c-cube 4y ago
    That's quite weird. These traits don't look like rust's traits, which really are a port of typeclasses from Haskell. I think the section about scala illustrates this well because scala's "traits" are an OO construct, but now scala 3 also" has typeclasses. So... Rust still isn't OO.
    - pjmlp 4y ago
      Ah, trying to go down that route? ECOOP 2009 proceedings paper from a certain Simon Peyton Jones. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://link.springer.com/chapter/10.1007/978-3-642-03013-0_1 https://link.springer.com/chapter/10.1007/978-3-642-03013-0_...

tannhaeuser 4y ago

Rust sucks for UI, async services, language runtimes, and a couple other things because memory usage patterns of those apps don't favor Rust's memory/safety model? I mean, who would've thought? Rust was introduced as a "systems" programming language after all, and doesn't have to be everything to everybody. Rust isn't even extensively used within its originating project/org (FF/Moz). IMHO, Rust's anti-C/C++ narrative also starts from wrong assumptions: in traditional Unix, what you're doing with C (apart from the OS) is implement the runtime of higher-level languages, but no-one has bothered to implement JavaScript or other engine with GC (let alone JIT) because committing to Rust's one-size-fits-all borrow checker just means the result can't be competitive. malloc()/free() also sucks, but its problems are only amplified by today's desire for single-process multithreaded or async backends; for one-shot commandline apps or process-per-request backends OTOH, there hasn't been much of a problem.

0atman 4y ago
Rust's 'one-size-fits-all' approach and the 'rewrite it in rust' movement are due to the language's high-level flexibility whilst also being as low-level as C. If you set out to write a new language in Rust, to escape the perceived limitations of the language, you end up extending Rust, not building a new language, and now you have Rust without the limitation you started with, and others can benefit from your work. I've written two videos on the topic that I'd love to know your thoughts on, the first talking about Rust's universality due to both the unsafe and macro systems: https://www.youtube.com/watch?v=PuMXWc0xrK0&list=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP&index=3 https://www.youtube.com/watch?v=PuMXWc0xrK0&list=PLZaoyhMXgB... The second a deeper dive into the macro system: https://www.youtube.com/watch?v=MWRPYBoCEaY&list=PLZaoyhMXgBzoM9bfb5pyUOT3zjnaDdSEP&index=16 https://www.youtube.com/watch?v=MWRPYBoCEaY&list=PLZaoyhMXgB...

classified 4y ago

Whoever designed the color scheme for that page has to be blind. But yeah, Rust's borrow checker is not designed for GUI apps.

satvikpendem 4y ago

I gave up and started using Flutter with flutter_rust_bridge for business logic. I'm convinced that UI development from scratch simply cannot happen without a large company backing the project, giving it time and money. Flutter took over ten years and likely millions of dollars. HTML, CSS, and JS / TS? Likely billions. This is because simply building the UI toolkit itself is usually not a prime motivator for a startup, they want to work on their differentiating features, not on reinventing the wheel. Of course, if the startup is a text editor or other such UI heavy app, then it may make sense to reinvent the UI wheel. Figma showed this successfully, and perhaps Zed and Warp might, too.

pas 4y ago
Oh, flutter + rust seems like a great combo. (Because Flutter seems great for UI work, but Dart is very meh for everything else.) Have you tried Tauri or some other Electron-like alternative by any chance? How do you like Flutter+Rust so far, and what's your "baseline"? :)
- beckler 4y ago
  I too am interested in the flutter aspect, but I just recently worked with Tauri as part of a rewrite project and it was a decent experience. There are still some rough edges and small gaps, but overall it’s pretty well done. Plus, when you’re ready to ship your app, they give you tools that make packaging and code-signing very easy. I would recommend it if you have any interest in it. Compare this to my experience with iced, where I discovered that I love the elm architecture, but dealing with the UI parts became exponentially more complex the larger it grew, so many undocumented or under documented components, plus upgrading between minor versions would cause breaking changes that weren’t always easy to solve because of the lack of documentation or examples.
- satvikpendem 4y ago
  I like Flutter and Rust, it's pretty nice. I actually like Dart as well, it has some very interesting features. I've used Electron and Tauri a bit before but I didn't like that it still wasn't "native," it still used a web wrapper.

jasmer 4y ago

UIs are inherently about state, and a lot of state is hard in Rust. The big 'tree of state' is just awkward. UIs are inherently async and event drive, it's callbacks over callbacks, again, harder in rust. UIs have a lot of detail. A little screen has a lot of hidden bit of small complexity. Rust is a heavy language that wants to treat every line of code as an existential security threat and performance. It's really not the right tool.

smodo 4y ago

Interesting that they are working with one of the Zed people. I’ve been wondering about the Ui framework they use. Opening up this framework could invite a lot of attention since they are dogfooding it in a (imho) solid product.

foldr 4y ago

As a relatively old person, I've had a few experiences of waiting for my favorite niche language to finally get a decent GUI library. In my experience, it never happens. It's just too much work. Only the most popular few programming languages in any given moment have usable GUI options. Even something as comparatively mainstream as Go lacks a good GUI story.

noelwelsh 4y ago

I'm confused by the discussion of OO. Just use an enum, aka algebraic data type, if you want control over the data. You can build an extension point into the ADT for user defined components, if that is desirable. The tradeoffs of OO style vs FP style vs having-your-cake-and-eating-it aka the expression problem are well studied. (This comment is a bit cryptic. Sorry. Don't have much time right now. Might return later.) My experience using ECS in bevy is it feels like fancy spaghetti code. I'm not convinced it's a great approach, at least on the small scale I'm working at.

cloogshicer 4y ago
Please do return later and elaborate on what you mean by having-your-cake-and-eating-it aka the expression problem. I'm super interested in this stuff and would like to hear more.
- mjburgess 4y ago
  The expression problem is, roughly, how easy it is to extend a program without recompiling it. OO is typically regarded as making it easier to extend the data types of a program, since you can introduce new ones by inheritance at any time. Whereas pure FP systems specify types exhaustively at definition. FP typically makes it easier to extend the functions, since you can define arbitary more functions on the "public" type system; whereas OO encapsulates stuff and makes it harder to do that. > You can build an extension point into the ADT for user defined components I assume that means there are ways of making the pure-FP approach OO-like, and vice versa. I think its nevertheless to speak about affordances here, and rust is in my view, one of the poorest DX/affordancey languages --- the syntax and semantics conspire to create lots of friction. This friction isnt really considered in "the expression problem", but i think is very important in practice. We should have a "frictionless expression problem" and I think that's the issue with rust: it doesnt frictionalessly extend in the ways needed by UI programming.
  - cloogshicer 4y ago
    Thank you for taking the time to explain!

rvz 4y ago

Perhaps the most obvious answer is that it is may not be the appropriate language for that use case? It is like suggesting to use Solidity or Assembly to build the UI for your app.

ummonk 4y ago

ECS essentially uses the relational-database-like data storage. To model a tree, ideally you would have ECS but with graph-database-like data storage.