Why is building a UI in Rust so hard?

https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard

by osener • 3 years ago

111 125 3 years ago

ar9av• 3 years 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.

taneq2• 3 years 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• 3 years 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_19h5• 3 years 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_dev4• 3 years ago

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

marton78• 3 years ago

I can confirm. I'm regularly surprised how slow my iOS developers are at developing a few screens.

illiarian3• 3 years ago

It's amazing how much we've regressed since Delphi.

cageface• 3 years ago

React Native is a lot faster for building out prototypes but slows down when you start building more complex screens and can be very brittle to maintain over time.

MrLeap2• 3 years ago

I always boggle a bit when somebody measures development velocity "by the screen"

It's smoke above pinched fingers creating a bottleneck. Whether the fingers belong to bureaucracy or dev capability requires more info than I have. My bias says look at whoever has the biggest ego and the strongest opinions. They're the anchor.

andrekandre2• 3 years ago

uikit or swiftui?

bmitc2• 3 years ago

I have been held back for years because of the sad state of desktop UI frameworks. I have recently embarked up creating my own, if only for my own purposes. It's a nightmare.

One of the primary issues is that there is no foundational cross-platform support. For creating windows, GLFW is the best bet. I should give kudos here. GLFW works and is well-documented, a rarity indeed. The forum is also pleasant. For graphics, Skia is probably the best solution, but it has problems. For example, it is 2D only, has support on a Google Group with not much traffic, and is complicated to build. The binding for it on .NET is currently not actively maintained, despite being effectively owned by Microsoft. You also give up performance. For example, Direct2D is much faster than Skia on Windows, and Direct2D can seamlessly interact with Direct3D in the same window. But SharpDX (the .NET bindings) is no longer maintained and DirectX is of course Windows only. Then you have macOS which is completely antagonistic. It is locked to an extremely old OpenGL version, and Apple may remove it at any indeterminate time. So you either build against OpenGL or start jumping through hoops in GLFW and Skia to use Vulkan and Molten to talk to Metal on macOS. Also, macOS is the only OS that forces the window management on the main thread. All window management on all OSs is on a single thread, but on Windows, for example, that thread can be any thread. Then there's Linux and the umpteen million distros and the two window managers in X11 and Wayland. There is no cross-platform accessibility library that I know of.

On top of all this, all pf these solutions have limited to no support. Most projects are ran by just a couple of people, if that. This is not a complaint against them in any way, as it is simply an observation of the reality in that support is highly, highly limited. There's also the issue that many of the issues encountered are complex and often reach across several stacks. For example, is it a bug in Skia, GLFW, the bindings to these, the OS, the graphics drivers, or from the interaction of these.

There are also very few resources and references for stuff like this.

riceart2• 3 years ago

For example, Direct2D is much faster than Skia on Windows

Much faster? I’m not necessarily doubting this but you have some evidence? Isn’t Skia even used by Edge? And everybody here is basically claiming that the only UI frameworks that matter are web based - so if it’s good enough for that…

Also Qt Quick - seems to cover all the platforms mentioned. Of course it has a ton of resources poured into it, but it’s there.

jffhn• 3 years ago

If I read your post correctly, you might be interested in reading the readme and maybe the code of this library I've been working on (even though it's only 2D, and (purposely) not advanced 2D): https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...

IshKebab• 3 years ago

Qt is pretty damn easy I would say. And some Web UIs are easy too.

In any case this article is talking about the features that are unique to Rust that make it especially hard to write GUIs.

Though weirdly it focuses on lack of inheritance which is definitely not that big of a deal (Rust does have trait inheritance - you can even get full implementation inheritance using macros if you really want but I doubt it is needed). The biggest issue by far is state management because of the single ownership rules.

You can of course Rc-RefCell everything but that gets very ugly.

recuter2• 3 years ago

This is a white whale for a lot of people.

http://www.areweguiyet.com (seems updates to this thing have stopped?)

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://news.ycombinator.com/item?id=35173866

jeroenhd• 3 years 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.

ttiurani• 3 years ago

Raph Levien, who's behind Druid and Xilem (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/1P8Su5mZSYkfZ1A9mPAaK...

cloogshicer4• 3 years ago

The first link especially is super insightful, thanks!

rayiner2• 3 years ago

Thanks for sharing this! Especially for linking the slides and not just the video.

paulsutter• 3 years ago

English is the new UI

amelius2• 3 years 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.

2muchcoffeeman2• 3 years ago

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

larnon• 3 years ago

I believe that is what Tauri is for.

linhns• 3 years ago

Because building an UI is hard?

dgb233• 3 years 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?

MrLeap2• 3 years 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• 3 years ago

Sorry, I read your comment twice but I have no idea what you're trying to say.

dgb233• 3 years ago

Not sure why your comment got downvoted. I’m also not sure I really understand what you’re saying, although I get the hunch that it might be a valuable description?

tgv• 3 years ago

But doesn't maintaining references using a hashmap mean that you've got to cleanup, which is basically (the hardest part of) memory management?

dgb233• 3 years ago

Exactly!

But the cool thing with laying out your graph like that, is that it has a relational character to it.

You’re essentially dealing in tables and (one/many) to many relationships.

You have a birds eye view of where your entities are allocated and how they are connected.

You still need policies around how you clean them up (remove an entity) and how the edges are affected. But you can reason about that in a similar way as you would in a relational database.

amelius2• 3 years ago

But in a sense it's cheating!

Once you start cheating you might as well write yourself a garbage collected language and use that to write your UI library.

epilys• 3 years ago

You're not circumventing the borrow checker though. You can only access a hashmap/vec entry if you have the right borrow of it's container. Unless you play around with unsafe, the hash map entries that stay in the container will live at most as much as the container.

This is what the borrow checker does. The index is just for doing an If let Some(entry) = map.get(&ident) {}

and not fail if it does not exist. Do you want to keep stuff alive even if they are removed? You can use reference counter wrappers (Rc and Arc) just fine.

The right pattern for graphs etc in vectors and maps is that the owning struct/type is responsible for keeping its internal state (indices it knows to exist) consistent. But that's not a memory safety issue, it's a logic issue

taneq2• 3 years 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 )

MrPatan2• 3 years 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• 3 years 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.

recuter2• 3 years ago

Somebody should just sponsor a minimal browser engine written in Rust. Bet it would be uniquely well suited for it. Wait..

BiteCode_dev4• 3 years 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• 3 years 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_19h5• 3 years ago

The biggest problem IMO is the insanely complicated layout system that is the way it is mostly because it was originally meant to handle long text documents. It took a while to bolt on enough things to have decent equivalents of app-centric approach to layout that desktop frameworks have offered for decades, but it still has to integrate with everything else in the spec, and devs need to know exactly what to look for. Ditto for styling. If you compare either to XAML or QML hands on, it quickly becomes clear just how much easier it is to work with the stuff that was designed for apps from the get go.

pjmlp8• 3 years ago

Except that is usually because many don't get how native toolkits work.

Ancient knowledge lost to the druids in the mountains and dead trees instead of TikTok tutorials.

This mage will always pick native over Web when given the option, even though Web has paid the bills most of the time since the last 25 years.

lagniappe4• 3 years ago

native toolkits

I get them, but I'm just not interested anymore with 3 desktop and 2 mobile platforms to think about. Sure it makes sense sometimes, but this should be fun.

saidinesh52• 3 years ago

Not really. The problem isn't about stylesheets. For the context, I have worked with Qt, QML, Gtk, jQuery, Sencha/ExtJS, React based codebases at various points of time in my career. Qt, Gtk both support stylesheets and no one complains. Everytime i had to deal with web frontend issues, I keep getting frustrated about how we are trying to make "Application UIs" out of what was meant to be a "Document description framework". Be it in Layouts. Be it in debugging. Be it when creating custom widgets/elements.

"You want a button? you have to style a div to get what you want". "You want to center an element vertically? You have to use a table. You have to use these css hacks." "You want to debug the component you've written? Enjoy diving through the div soup".

Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc.. based frameworks. Hell even the imgui, qt etc.. have webassembly/webgl targets. But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization.

The only good things I have to say about electron: They have decent free tooling that makes producing cross platform binaries easy/easier than the native alternatives. Accessing http resources in javascript is nicer than trying to do the same in C++/Java/etc... The latter is a very important consideration in this day and age.

parasti• 3 years ago

Your anecdote about the button and vertical alignment doesn't really hold. Vertical alignment has been a solved problem for many years thanks to flexbox. And obviously, use a <button> tag to make a button.

seanalltogether• 3 years ago

I couldn't agree more, html was designed as a simple way for users to create documents, not interactive applications. IMO stylesheets are the only good feature from html worth pulling into the app ecosystem, but otherwise I really dislike the trend of bringing web technologies designed to solve the limitation of web pages or stateless servers into desktop/mobile application development.

thiht3• 3 years ago

how we are trying to make "Application UIs" out of what was meant to be a "Document description framework"

We try, we can, and we do. Successfully.

"You want a button? you have to style a div to get what you want". "You want to center an element vertically? You have to use a table. You have to use these css hacks." "You want to debug the component you've written? Enjoy diving through the div soup".

Honestly I don’t think you’re entitled to an opinion on this given you obviously haven’t done anything web related in the last 20 years. I mean, even <button> was there from the beginning. Flexbox layout itself is almost 10 years old now. CSS hacks are mostly unheard of since the death of Internet Explorer 9.

foldr2• 3 years ago

"You want a button? you have to style a div to get what you want"

No, you don't, there's a <button> tag. If you don't like the default button style, then yes, you'll need to style it. But that goes for any UI framework.

rikroots• 3 years ago

Of course, there's nothing stopping us from being able to use just a Canvas/WebGL/etc [...] But so far, they seem to do badly when it comes to content addressability, accessibility and search engine optimization.

In my experience the key to solving accessibility etc, when building out a canvas-based web UI, is to work with the DOM instead of trying to replace it. Use <input> to control the placement and display of graphical elements, <button> elements to start/stop animations, etc; make good use of DOM events to track user movement/interaction across the canvas; tie clickable actions to real <a> elements instead of trying to reinvent them. Graphical text also needs to be reflected back into the DOM. Good use of ARIA also helps. Etc. And don't be afraid to tap into CSS --variables or even HTML data- attributes: not everything needs to be defined in the JS (or WASM-enabled language of choice) canvas code if the end result - a <canvas> UI or infographic - is destined to live in a web page.

Proof-of-concept of an accessible design system: https://codepen.io/kaliedarik/project/editor/DVeMVj

Proof-of-concept of an accessible set of related graphs: https://codepen.io/kaliedarik/project/editor/AMVKPx

bitL7• 3 years ago

Delphi designed in the 90s is still far superior to any web technology for building UI - you can make a complete standalone app in a few hours instead of weeks. IMO JavaScript was pushed by some large corps in order to commoditize developers and also because that was about as much programming as many decision makers were capable of understanding. Now we have the Node.js/React/Electron cancer everywhere making simple things overcomplicated for 99.9% of use cases.

thiht3• 3 years ago

Delphi designed in the 90s is still far superior to any web technology for building UI

Then where is it?

Also, I can make a standalone app in a few hours using Electron. I guess it would take me more than a few weeks with Delphi, given that I don’t know anything about it. So your point might just be that you know Delphi and not JavaScript.

codethief• 3 years ago

What exactly made it superior? I remember working with Delphi in high school and, in hindsight, it seemed much less powerful than web technologies.

graboid2• 3 years ago

Hours instead of weeks? What makes you assume that? An experienced web developer can iterate pretty damn fast.

I can understand the appeal and advantages of using native GUI tech. Really. But there is a reason people use stuff like Electron/Tauri/Wails. Web tech has seen so much investment, and as a result, you now basically have a app platform that runs anyhwere, offers a huge ecosystem and a great developer experience. Which I never found to be matched in any other GUI toolkit.

If there was a GUI toolkit that offered me all of this without requiring the bloat of a browser, then I would switch in an instant. It's just not there.

rwalle• 3 years ago

Your comment is an example where people have no idea what they are talking about but just making things up.

"In a few hours instead of weeks" I'd argue that the web stack only takes less time, not more.

JavaScript is popular because developers like it, because it works well, not because some "large corps" "push" for things to happen. There are more than scattered evidences to show that.

Next time, come up with something better and more convincing when hating the web stack.

MrPatan2• 3 years ago

Far superior... at making basic 90s UIs that nobody else wants today.

For better or worse, but the reality is nobody wants them anymore. Branding is a thing. When a client wanted something different you used to tell them "You can't have that" and they had to take it, because there was no other option.

The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.

BiteCode_dev4• 3 years 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

pjmlp8• 3 years 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

"Authoring ActiveX with VB 6"

https://learn.microsoft.com/en-us/previous-versions/visualst...

"Traits - Composable Units of Behavior"

https://scg.unibe.ch/research/traits

"Working with Protocols"

https://developer.apple.com/library/archive/documentation/Co...

andrekandre2• 3 years ago

to that point, traits themselves originated first in smalltalk correct??

pjmlp8• 3 years 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.

eternalban• 3 years ago

Thanks for the links.

Container. Component. Context. Graph. I would think a "wonderful language" such as Rust should have no problem with such a basic conceptual setup, but apparently not. I personally am solidly in the adaptive components camp, specially for things like UI.

If you know Rust (I don't), curious if the monadic approach could work, propagating the state as a parameter.

tannhaeuser• 3 years 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• 3 years 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=PLZaoyhMXgB...

The second a deeper dive into the macro system: https://www.youtube.com/watch?v=MWRPYBoCEaY&list=PLZaoyhMXgB...

classified• 3 years 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.

satvikpendem2• 3 years 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• 3 years 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• 3 years 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.

satvikpendem2• 3 years 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• 3 years 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• 3 years 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.

foldr2• 3 years 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.

noelwelsh2• 3 years 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.

cloogshicer4• 3 years 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• 3 years 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.

noelwelsh2• 3 years ago

I agree with the sketch given in the sibling comment. I think this is the paper from which I learned this: https://www2.ccs.neu.edu/racket/pubs/icfp98-ff.pdf

Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:

- data types a la carte, which takes an FP style approach; and - tagless final or object algebras, which takes an OO style approach.

Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.

Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.

In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.

tyingq3• 3 years ago

I'm confused by the discussion of OO

I don't think anyone's saying you can't do it without OO. Just that existing popular patterns for UI tend to rely on OO patterns like inheritance and classes with instances, and easy-ish namespacing and ownership concepts that map to those ideas.

So doing it without OO is harder, as it requires something different, that may be studied, but is less well explored and documented to the average person.

I recall similar discussions about doing UIs in C. GTK, for example, sort of fakes OO in C, I assume for related reasons.

hdhrufjdi2• 3 years ago

All frameworks that I know for WebApps, don't rely on OO though.

React, Angular (esp. with ngrx), Svelte

Yew and Leptos don't fake oop either

rvz• 3 years 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.

pvinis• 3 years ago

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

ummonk• 3 years 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.

Why is building a UI in Rust so hard?

Related Stories