Yes, and it is quite pleasant imo, for example in dioxus you can basically write html in a macro and is just works Macros are the backbone as far as my opinions go (generate boilerplate from html like language)
Lack of inheritance puts no restrictions on how UIs are built. If anything, there's more and more trend towards getting rid of inheritance and OOP in general (take react hooks for example). What's challenging in Rust is sharing of mutable data. If 2 components can modify the same view / same data (e.g. clicking menu icon can open a menu, and clicking close button or overlay can close the menu), that means both components need mutable references to the same data, which is disallowed in Rust. This is solved, usually through RefCell or something like it, but it's not as easy as in other languages, though I'd say every UI framework has already come up with good solutions for this and many have decent DX. I don't think the argument about inheritance makes any sense, and criticizing one example of trait implementation doesn't lead to a general conclusion that Rust is too limited for building UIs in any way. Rust doesn't have less capabilities than other languages, but Rust has less magic and fewer ways of shooting yourself in the foot. If you want to understand and fully control the memory and speed of your application, I'd say Rust is actually preferable.
As you said, the issue is that it is not as easy as in other languages, so you have to come up with different approaches, which is the main point of this video explaining why it is difficult and how to resolve it.
Inheritance is very very handy when designing such systems and rust just throws it away and don't give you any good alternatives to do it. I think the core team and many fans of rust are just haters of OOP and they will never agree that sometimes OOP is really useful. They just throw it away completely without giving you any good alternatives
@@32zim32 no. Rust is perfectly suitable for building UIs. If you want more magic and less control, Rust might not be the best option, but if you want more control over speed and memory, Rust is a great option. Even that is not exactly correct, because Rust has libraries that abstract away low level details and give you a lot of magic instead. So, Rust is good in either case, just beware that Rust gives you more control that you may not be used to.
This is ironically a common Trend I see in more complex rust programs. Using owning relations gets prevented by the borrow checker, so people invent this "index into an array" method, to circumvent the borrow checker. Issue is, then you kinda reinvented pointers, only that the rust system does not "know" about them and thus cannot check them. This also means there is no mechanism preventing you from accidentally using the wrong index into the array. This is similar to the memory bugs rust tries to avoid, just one level higher.
You can only use the wrong index into an array if you remove elements in a way that everything after the removed element has to be moved. But with normal pointers, it also happens when your vec is reallocated. There's still a problem being solved.
@@Speykious If each element had a vector of pointers to their child elements, you can remove elements safely and still be sure that the tree structure is not damaged.
It's not the same as pointers in that you won't experience undefined behavior. You can argue that panics are just as bad, but that's the whole thing about Rust: it only guarantees lack of UB, not panics.
I mean, rust has pointers if you want them. It just requires unsafe to dereference them. If someone does a lot of stuff just using a method taking an index, why not just use a reference with a lifetime straight up? I guess it takes people a few weeks or months to get that if they come from programming languages that don’t have lifetimes, but still.
Personally i like the "egui" crate the most. You create UI elements not by creating objects, but by calling functions. Your code sits inside a big closure that is called each frame, therefore your UI is rendered every frame - no need for component management, if you don't want to draw something based on a condition, you just put the drawing call into an `if`.
@@invinciblemode It does take more resources, but for my usecase (mostly simple apps composed of regular widgets and simple drawing into canvas), it's more than fast enough.
@@thekwoka4707 I don't know if it's faster or slower than React, but since it is native code (or wasm), it won't have the overhead of a JS interpreter. I don't pretend to know how react works, so i'm not to judge.
@@user-vn9ld2ce1s this is just a classic case of not everything WASM is better if the architecture is flawed to begin with. Nothing is more performant than JS when it comes to managing UI that uses native browser DOM nodes. If you’re not using DOM nodes (think apps like Figma, SketchUp, photoshop, webGL, etc) then WASM brings native desktop level performance to the browser (in those use cases only!)
Linus Trovald in a recent interview said that, Rust is not used in Linux Kernel as stated at the beginning of this video. There’s no need actually to replace C by Rust. Since C is a better language when it comes to interact with hardware
I really don't understand why you compare Rust and React. Rust is low level programming language, React is a js library. How do you compare these two ? I have never seen comparison between C and React or C++ and React. Maybe your next video title will be comparison between HTML and Java 🤣
Rust does not "lack" object oriented programming. It supports it in almost the same way that C++ does, even with multiple inheiritance. Instead of "extending" a class, you just have another struct as a member. To make the "derived" class act like one of it's members, impl the Deref trait to allow it to be borrowed. This use is what the Fyrox game engine uses. Please don't make it more difficult to find Rust programmers for hire buy discourraging its use. We need more Rust programmers.
Exactly. OOP is about keeping functions that operate on data, with that data. Its about dealing with data at a higher level of abstraction (the interface or trait) rather than directly manipulating it yourself. Rust supports this.
@@AshishSinghh While Go has inheritance by not giving a member a name, Rust gives the member a name and an impl of Deref lets you use the type as if it were another, so Deref is applicable to more than inheritance (the "new-type" pattern, smart pointers, etc.).
In the AMIGA days there also was no object oriented Model for doing GUIs, but AMIGA had GUIs, Windows a long time before Microsoft Windows was a thing. There are C-libs for graphics out there like raylib or OpenGL that also need to update alot of events and have to organize that. With C you need to build your own structures and data organization, because C is a very primitive language. So the big picture could yield from the question: How did they do this with those minimal resources, and how can we transfer this to the Rust-world? Another good sort of information would come from game programmers like for instance Casey Muratori. With the object oriented approach you miss the cache alot. So I think a Module based approach is better, like you are already following. A Module that handles all the drawing in the GUI framework can utilize the CPU cache well better, reducing performance-headaches. There are, frankly better, solutions out there that do not need object orientation at all. So it is definitively doable.
Back in the day, most people used terminal applications not gui's. Building actual gui's was extremely painful, time consuming and expensive. The OO model was developed to deal with this problem. Initially OO was used in libraries that constructed objects and methods. This proved to be not so ergonomic and since people thought that gui's are the future, the model was built into languages like objective C, C++, Java and C#. Actually, the elm model is quite nice to use. It's not really functional, it didn't come from functional languages but it was easy to implement in functional languages like Haskell. Similarly, I guess it's also convenient in Rust? (I've never built a gui in Rust, so I don't know.)
I've not run into these "big headaches" writing GUIs in Rust. Event handling and message passing is so easy in Rust. My GUIs typically use a tree structure and the root component has an event loop where it receives events and dispatches them to sub-components that handle the events that they can handle in their event loops. No need for interior-mutability.
Thank you for the eloquent description of the current issues concerning Rust GUI development. I’ve been attempting to learn enough Rust programming techniques to effectively implement it as a standard programming base for my embedded projects, but get a big doss of vertigo when trying to get up to speed on any of the GUI options.
I agree on everything in this video. Building GUI with Rust frameworks/tools is over ambitious. Perhaps it's too early for that. I separate FE from BE. I use Go/Rust for BE and React/Flutter for FE - the best so far IMO.
Traits are interfaces. Rc, Arc, and RefCell exist. If you can't figure out how to make a UI with those tools, you suck at Rust. There are tons of Rust UI libs. The way you hide the complexity is by just keeping it inside the library.
I didn't quite catch the relationship between hierarchy in OOP, the component tree (a.k.a. tree data structure), and the lack of inheritance in Rust. It's completely possible to build a tree structure in Rust, just like your example for React or how it's done in Angular. If the lack of a common type is the problem, you can use "dyn Component" which should work as a common trait for all components. I'd appreciate if you could elaborate a bit on this, because the way it's explained in the video might misinform people.
Hey! Thanks for asking. If you want more technical details and code snippets, check our our written blog here: www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard
@@warpdotdev thank you a lot for clarifying!! The article explains more clearly the problem, and even addressed possible solutions. Coding in Rust is indeed challenging after years of the Java way of OO in the majority of OO languages, while many frameworks do exactly what is described in the article (mutate the base class property for example), many would say it's a bad approach of doing things, and while there are workarounds for that in Rust, I don't think it'd be idiomatic. Awesome work on this!
You were a lot more polite than I think I would've been. Was about to point out that class hierarchy is a different concept to the tree like DOM structure react uses. You could implement such a tree like structure in Rust but admittedly there still are some somewhat unwieldy aspects to that due to how borrowing and ownership works in rust (in all likelihood you'll struggle to create a tree which you can modify easily and safely)
Fantastic video. I’m not sure I fully followed everything, but I think that’s mostly on me. Do you think the issues you raise are those that UI developers have to contend with or just framework developers? I feel like procedural macros fill in some of the gap left by the lack of inheritance
How is writing GUI libraries in Rust more difficult than writing them in plain C? Most GUI libraries were written originally in C, not even in C++, and in C you don't have any OOP.
10 месяцев назад+6
Anything OOP can do, traits can do better. The mutability thing is not really a problem in Rust. Problems with references and the borrow checker? Use smart pointers. Accessing smart pointers is very performant, like accessing references (without optimizations). Iced is amazing, but still lacks many features.
Are a learner? IGNORE THIS VIDEO. Sorry but this video is completely wrong on several different levels. Inheritance is NOT needed for tree-like structures. Borderline propaganda-like. Who fact-checked this?
I wouldn't want to create a ui in rust, just a backend that returns json data, and I would delegate the front-end to any framework of your choice, React, Vue, Astro, Svelte, Flutter, you name it
Found your channel from coding with Lewis and I subscribed 🙌 The quality of video is 🔥 The knowledge given is 🔥 Thanks and bring more content like this
Can you elaborate more on the Entity Component Structure method? What sort of GUI library for Rust does this? Did you have to write up your own? If so does this mean other people writing Rust GUI should stick to the Elm-inspired libraries like Iced?
Rust probably has more object-oriented features than your average Java clone. There are traits (powerful interfaces) instead of abstract classes, and "inheritance" is achieved through them; that is, every struct that implements a trait X de facto "inherits" it so it can be dynamically dispatched to a trait X object. It's really just a more recent and flexible approach.
You can do a lot more in rust than is apparent right out of the box. I bet you could theoretically do classes with inheritance using macros and you can use data structure with interior mutability as mentioned in the video or if you really want to you could “unsafe{}” it all and build your own model on top of that. You could even implement a garbage collector if you really wanted to. It’s just that rust can give you some nice guarantees if you figure out how to do things according to the safe borrow rules, and to be honest, you might have to do a lot of work to get some of those other things going, on par with designing your own programming language. To be fair, gui libraries are almost that anyway, with how much terminology is required to reason about them. There is a lot of experimentation going on in the gui space currently and it’s very fun to follow. Even if it might be worth while to wait a bit before betting on rust gui if you want to do anything really serious, I don’t think things will stay that way for long.
The thing is that macros are really difficult to use in my opinion. They're best left as "magic" that the programmer doesn't have to think about. What you're proposing is can only work with heavy use of macros and traits, some of the hardest things in the language.
@@user-uf4rx5ih3v I think I agree. (Guessing you refer to the part about classes and inheritance). I don’t recall the whole context of why I wrote the comment. Using macros can be easy, it can be hard. It depends on the macro. Writing simple ones is quite easy but requires a slightly different skill than using them. Writing macros that would do classes and inheritance… would take some work for sure. I’m not advocating that everyone and their grandma should do this on their own in their projects. I’m probably not advocating that people should do it at all. But just in principle if someone does write some set of macros that allow code that works like classes with inheritance, you could just add that library to your project and use the macros. Maybe there is a design that would make the user experience easy. At least as easy as the notion of classes and inheritance, which maybe isn’t simple in itself. I’m not advocating this. It might be a terrible idea. Probably is. You can tell me if it sounds like we agree. 👍
I agree overall, most of the time and energy is spent on making Rust a good backend or systems programming language instead of a good front end language. Rust feels underdeveloped in this regard
I think web assembly is also a bottleneck for this. Although in my opinion leptos and yew are also nice flavours if you know solid or react/next. We might get a really nice full stack solution from Rust. Meanwhile the tooling for the frontend is still being innovated on through Rust at the moment.
I guess I'm just missing the point. If you want to build a user-mode app with a GUI, you use C# or . Why would you even consider Rust or C or C++? I mean, I guess if you're writing code for a super resource-constrained system, but that's a pretty specialized niche. Microsoft is using Rust for what it's best at: system level programming. They're doing Azure development in Rust, as well as re-writing some of the Windows system binaries in Rust. And if a developer doesn't want to worry about memory management, they have no business writing a device driver or a kernel binary. This just seems like a moot point. It's addressing a straw-man scenario. Or, I guess I should allow for the possibility that the world is a weird place, and there are strange people who do inexplicable things. Are there really people that voluntarily choose to write GUI apps in Rust? What's their motivation? The extra performance simply doesn't matter, at all. On the other hand, is there anyone seriously arguing that Rust isn't a very valid, and perhaps even objectively correct, choice for systems level programming? I mean, I did my share of kernel development in C 25+ years ago, and to this day it's the language that I am most comfortable in, but surely even the most die-hard C or C++ developer would allow that Rust is at least a nice option?
It is almost as the person in this video doesn't know object oriented programming. It also looks like it doesn't understand how to handle memory allocation.
We're evaluating Rust as a possibility in modernizing a huge CLI system written in C and TCL. (It is very very old). So far I've found it to be unfamiliar and difficult. It is not really OO and not really functional. It has no garbage collection. It has very high interest among developers for some reason and is the reason we are considering it because we could more easily attract top software engineers. (Our team is entirely made up of 60ish year olds)
Good question! We talk about some of the safety concerns of using interior mutability in our blog here: www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard
🎯 Key Takeaways for quick navigation: 00:31 🧐 Building a graphical user interface (GUI) in Rust is challenging due to Rust's unique features like ownership and mutability rules. 03:44 🔄 Rust's lack of object-oriented programming makes it difficult to create a top-level component that controls a GUI tree, unlike languages like React. 06:51 🧠 One solution for Rust GUI development is adopting the ELM architecture, which consists of model, view, and update, or using an entity component system (ECS) architecture. 08:20 🌐 In Warp, they implement an ECS-style approach with a system that owns components and maps their relationships, providing a way to create a GUI tree without relying on inheritance. Made with HARPA AI
It seems the entire Rust community is using reverse psychology to up their views. Seriously, is there anything straightforward about Rust? Anything at all?
Tauri isnt to bad for Devs, coming from JS background. I have focus to Tauri with Svelte, as it seems to me quite all in one thing to me. If you do perhaps know like QT for C++. I bet, Rust does have something similar. However, I would not blame Rust for being not good for UI, as it probably offers to many confusing ways to do stuff, if you think in a monolith. Even your MVC approach is unsure to me, as it might lead to blowing up the code.
Interesting take. I'm new to rust and really enjoy it. Now that I've thouroughly indoctrinated in the crustacean ways. I'm in the mood for some criticism and learning about the pitfalls of rust. Most videos I found were just masked rust propaganda or people that didn't seem to get the point of rust. Glad to have bumped into this video. This was a breath of fresh air with a well explained and pretty unbiased. That gets you a like! And the policeman crab with the moustache earned you a sub.🦀
Currently I am starting to create a VST3 (or maybe Clap) DAW plugin featuring a GUI in Rust. Hence the HUI framework needs to get the Window context from the DAW via the plugin API. Once I am able to a non-GUI plugin I will start evaluating GUI frameworks, supposedly starting with ICED.
Js is for the Dom and it should stay that way. Each language has its strengths and rusts' is in threading and memory management, along with a few others from what I know now
I am a C++ programmer, but I am looking for ways to implement GUI with an ECS as well. I believe it can be done in a way that code is fast, and API is easy for the user.
Nice video but inheritance and OOP is NOT a cumbersome feature..... we have interfaces (traits) that makes life easy as well. and composition is easier to handle , sure, but just cause other langs offer class inheritance doesn't make it inherently evil
Yeah, during the whole video I was just thinking: ".... we can just do it like elm does" I wasn't expecting ecs tho, even though I got interested in rust because of bevy
I've seen people write an assembly or another language block inside rust code, maybe GUI is best done that way. Like letting rust do what it does the best, run core code really fast and safe, but separating the GUI to something evil rust shouldn't touch. After all, isn't multiple languages in a project a very common thing already? Like most of the time for web stuff you just have to step into the javascript world to save yourself from more pain.
This video was fantastic in content but visually a little bothersome. Making text hard to read (script vs plain) and then animating it (pulse) and not leaving it on screen long enough really took away from what you were trying to say imo.
It hearkens to a reductive existential contradiction of rust's very safety. Does it mean that one of these methods simply has to "admit" and "embrace" the inevitable? It seems important to choose tools that embrace the inevitable - if it's the inevitable.
The lack of class hierarchy doesn’t mean you can’t organize components in a tree structure, huh? You could easily define a trait with componentDidMount() and similar functions, even a children() function that returns an impl Iterator
I'm using rust a lot in the backend, it's a life saver for me. To build uis for the web though... Not so much. Also if you need to build desktop apps rust is definitely a good choice to use in the place of c++.
I don't think Rust even comes close to C and C++ in terms of desktop applications for 2024. That situation might change in a decade, or perhaps it will never happen. Just look at the most popular desktop environments for Linux, such as KDE and GNOME; most of them use C and C++ libraries like Qt and GTK. Despite efforts to port these libraries to Rust, it remains-and will likely always be-a second-class language in this domain.
I was thinking how you could look into the camera while talking so people feel like you are talking to them... How about you create a dead zone in the middle of the monitor. Set up your camera in the dead zone. 😊
Hey! Good question. The primary reason is that login allows us to build cloud-oriented features that make the terminal have a concept of “your stuff” and “your team’s stuff” - for example Block Sharing. This is the same reason other collaborative apps like Figma and Github require login - identity is the basis of building cloud-native apps. That said, we understand the desire to try Warp before logging in, and are exploring product experiences that will allow users to preview Warp before signup.
@@warpdotdev that makes a lot of sense. it was always kind of a turn off for me when i was trying warp, but ill def give it another try now that i know its not JUST telemetry. thank you very much and keep up the good work
@@rossdafodil7931 Nice! By the way, our telemetry is opt-out. Here's the documentation on how to disable it, if you want. docs.warp.dev/getting-started/privacy#how-to-disable-telemetry-and-crash-reporting
In short, we chose Rust because of its speed and also its strong developer community (for example, using crates.io for package management was a breeze and our entire team onboarded very quickly with tools like Rustlings). More importantly, Rust has a pretty extensive platform support--allowing us to write in a single language and then build for Mac, Linux, Windows, and ultimately the web by compiling to WASM. If you want to read more about how Warp was built, check our our blog here: www.warp.dev/blog/how-warp-works
i think you shouldn't swap to camera if you're reading a script, just looks like you have lazy eye, but you're really interesting to listen to otherwise
Well it shouldn’t do. I think part of the problem is that your expectations have been skewed partly due to the misleading title. You should the right tool for the job.
In short, we chose Rust because of its speed and also its strong developer community (for example, using crates.io for package management was a breeze and our entire team onboarded very quickly with tools like Rustlings). More importantly, Rust has a pretty extensive platform support--allowing us to write in a single language and then build for Mac, Linux, Windows, and ultimately the web by compiling to WASM. If you want to read more about how Warp was built, check our our blog here: www.warp.dev/blog/how-warp-works
This is actually the opposite of my expectation about Rust. The reason why I want to change from kotlin to rust, because I want to use pointer but in a safe way. Pointer to a structure or class is better than inheritance.. Why do you think placing a pointer to the event loop is inefficient?
Are you using Rust to build UI? 🤔 Let us know!
I’m just starting to know the language… so are you saying that rust isn’t up friendly?
@@challow90221 Rust is awesome and you should learn it! It's just in the early stages of building UI :)
@@warpdotdev thanks. I meant to say “UI” not “up” lol I’m glad you figured out my blunder.
Yes, and it is quite pleasant imo, for example in dioxus you can basically write html in a macro and is just works
Macros are the backbone as far as my opinions go (generate boilerplate from html like language)
> Rust is not OOP
It is OOP, just don't have regular inheritance.
Get ready for a Primeagen reaction
We’re ready
Waiting
@ThePrimeagen
3:16 wll trigger him so bad
hah you mean waiting for the reaction of the cringy opinionated man?
Isn't this a click bait? You didn't explain why we shouldn't use Rust and started explaining all Rust features.
Welcome to internet
She explained this using an example comparing react to rust. Just because you didn't understand the explanation doesn't mean it's not there.
"Imagine having a button that doesn't do anything when you click on it".
This is how my apps work now
We've all been there....
Commenting before this comment blows up
Isn't this better than a button that does do a wrong thing when clicked, but only sometimes?
@@lakshitgupta3025 Still waiting for the comment to blow up.
@@lakshitgupta3025 Still waiting...
Lack of inheritance puts no restrictions on how UIs are built. If anything, there's more and more trend towards getting rid of inheritance and OOP in general (take react hooks for example). What's challenging in Rust is sharing of mutable data. If 2 components can modify the same view / same data (e.g. clicking menu icon can open a menu, and clicking close button or overlay can close the menu), that means both components need mutable references to the same data, which is disallowed in Rust. This is solved, usually through RefCell or something like it, but it's not as easy as in other languages, though I'd say every UI framework has already come up with good solutions for this and many have decent DX. I don't think the argument about inheritance makes any sense, and criticizing one example of trait implementation doesn't lead to a general conclusion that Rust is too limited for building UIs in any way. Rust doesn't have less capabilities than other languages, but Rust has less magic and fewer ways of shooting yourself in the foot. If you want to understand and fully control the memory and speed of your application, I'd say Rust is actually preferable.
As you said, the issue is that it is not as easy as in other languages, so you have to come up with different approaches, which is the main point of this video explaining why it is difficult and how to resolve it.
Rust is not too limited but it is not suitable for building UIs. That's correct?
Inheritance is very very handy when designing such systems and rust just throws it away and don't give you any good alternatives to do it. I think the core team and many fans of rust are just haters of OOP and they will never agree that sometimes OOP is really useful. They just throw it away completely without giving you any good alternatives
@@32zim32 no. Rust is perfectly suitable for building UIs. If you want more magic and less control, Rust might not be the best option, but if you want more control over speed and memory, Rust is a great option. Even that is not exactly correct, because Rust has libraries that abstract away low level details and give you a lot of magic instead. So, Rust is good in either case, just beware that Rust gives you more control that you may not be used to.
@@kirglow4639 time will show. Right know we don't have mature rust UI libraries with big success stories
This is ironically a common Trend I see in more complex rust programs. Using owning relations gets prevented by the borrow checker, so people invent this "index into an array" method, to circumvent the borrow checker. Issue is, then you kinda reinvented pointers, only that the rust system does not "know" about them and thus cannot check them. This also means there is no mechanism preventing you from accidentally using the wrong index into the array. This is similar to the memory bugs rust tries to avoid, just one level higher.
You can only use the wrong index into an array if you remove elements in a way that everything after the removed element has to be moved. But with normal pointers, it also happens when your vec is reallocated. There's still a problem being solved.
@@Speykious If each element had a vector of pointers to their child elements, you can remove elements safely and still be sure that the tree structure is not damaged.
It's not the same as pointers in that you won't experience undefined behavior. You can argue that panics are just as bad, but that's the whole thing about Rust: it only guarantees lack of UB, not panics.
I mean, rust has pointers if you want them. It just requires unsafe to dereference them.
If someone does a lot of stuff just using a method taking an index, why not just use a reference with a lifetime straight up? I guess it takes people a few weeks or months to get that if they come from programming languages that don’t have lifetimes, but still.
That sounds like a lot of headaches.
Personally i like the "egui" crate the most. You create UI elements not by creating objects, but by calling functions. Your code sits inside a big closure that is called each frame, therefore your UI is rendered every frame - no need for component management, if you don't want to draw something based on a condition, you just put the drawing call into an `if`.
Sounds not performant
@@invinciblemode It does take more resources, but for my usecase (mostly simple apps composed of regular widgets and simple drawing into canvas), it's more than fast enough.
So basically react but slower?
@@thekwoka4707 I don't know if it's faster or slower than React, but since it is native code (or wasm), it won't have the overhead of a JS interpreter. I don't pretend to know how react works, so i'm not to judge.
@@user-vn9ld2ce1s this is just a classic case of not everything WASM is better if the architecture is flawed to begin with. Nothing is more performant than JS when it comes to managing UI that uses native browser DOM nodes.
If you’re not using DOM nodes (think apps like Figma, SketchUp, photoshop, webGL, etc) then WASM brings native desktop level performance to the browser (in those use cases only!)
Sorry for nit pick. ReactJS isn’t a programming language -> 3:19
It’s a programming language for people who previously used jQuery programming language;))
Linus Trovald in a recent interview said that, Rust is not used in Linux Kernel as stated at the beginning of this video.
There’s no need actually to replace C by Rust. Since C is a better language when it comes to interact with hardware
Bro it's open-source, just take a look
Rust isn't in the kernel, but it is better.
I really don't understand why you compare Rust and React. Rust is low level programming language, React is a js library. How do you compare these two ? I have never seen comparison between C and React or C++ and React. Maybe your next video title will be comparison between HTML and Java 🤣
i think she wanted to explain the difficulty of building UI design based on Rust. so i guess React is just mentioned in terms of UI design with Rust
didn't. even watch the video and yet you are bitching.
Rust does not "lack" object oriented programming. It supports it in almost the same way that C++ does, even with multiple inheiritance. Instead of "extending" a class, you just have another struct as a member. To make the "derived" class act like one of it's members, impl the Deref trait to allow it to be borrowed. This use is what the Fyrox game engine uses. Please don't make it more difficult to find Rust programmers for hire buy discourraging its use. We need more Rust programmers.
Exactly.
OOP is about keeping functions that operate on data, with that data.
Its about dealing with data at a higher level of abstraction (the interface or trait) rather than directly manipulating it yourself.
Rust supports this.
sister you genius
like Golang?
@@AshishSinghh While Go has inheritance by not giving a member a name, Rust gives the member a name and an impl of Deref lets you use the type as if it were another, so Deref is applicable to more than inheritance (the "new-type" pattern, smart pointers, etc.).
I’ve never seen anyone mention the Deref trait. Ever. Thank you for mentioning it. It could be so useful.
In the AMIGA days there also was no object oriented Model for doing GUIs, but AMIGA had GUIs, Windows a long time before Microsoft Windows was a thing. There are C-libs for graphics out there like raylib or OpenGL that also need to update alot of events and have to organize that. With C you need to build your own structures and data organization, because C is a very primitive language. So the big picture could yield from the question: How did they do this with those minimal resources, and how can we transfer this to the Rust-world? Another good sort of information would come from game programmers like for instance Casey Muratori. With the object oriented approach you miss the cache alot. So I think a Module based approach is better, like you are already following. A Module that handles all the drawing in the GUI framework can utilize the CPU cache well better, reducing performance-headaches. There are, frankly better, solutions out there that do not need object orientation at all. So it is definitively doable.
And they were all horrible to use. Seriously have you actually used them? Why donyou think they were replaced in the first place
Back in the day, most people used terminal applications not gui's. Building actual gui's was extremely painful, time consuming and expensive. The OO model was developed to deal with this problem. Initially OO was used in libraries that constructed objects and methods. This proved to be not so ergonomic and since people thought that gui's are the future, the model was built into languages like objective C, C++, Java and C#.
Actually, the elm model is quite nice to use. It's not really functional, it didn't come from functional languages but it was easy to implement in functional languages like Haskell. Similarly, I guess it's also convenient in Rust? (I've never built a gui in Rust, so I don't know.)
Amiga first edition 1985. Windows - 1985. Definitely it is not "long time before". LOL
More content like this please, getting fireship vibes here nice balance of educational and fun
I've not run into these "big headaches" writing GUIs in Rust. Event handling and message passing is so easy in Rust. My GUIs typically use a tree structure and the root component has an event loop where it receives events and dispatches them to sub-components that handle the events that they can handle in their event loops. No need for interior-mutability.
Why you don't use for this brainfuck?
Thank you for the eloquent description of the current issues concerning Rust GUI development. I’ve been attempting to learn enough Rust programming techniques to effectively implement it as a standard programming base for my embedded projects, but get a big doss of vertigo when trying to get up to speed on any of the GUI options.
This is why Tom is a genius and you should build your app on JSDL
We need to stop wearing this joke down to the bone
Why don’t you guys open source your GUI
I agree on everything in this video. Building GUI with Rust frameworks/tools is over ambitious. Perhaps it's too early for that. I separate FE from BE. I use Go/Rust for BE and React/Flutter for FE - the best so far IMO.
Spot on. I also built separately, FE in JS and BE in Rust.
have you ever tried leptos+htmx (for rust) or templ+htmx (for go)?
Rust -> wasm, wasm-pack
@@greycell2442
Overkill for very little gain
Traits are interfaces. Rc, Arc, and RefCell exist. If you can't figure out how to make a UI with those tools, you suck at Rust.
There are tons of Rust UI libs. The way you hide the complexity is by just keeping it inside the library.
I didn't quite catch the relationship between hierarchy in OOP, the component tree (a.k.a. tree data structure), and the lack of inheritance in Rust. It's completely possible to build a tree structure in Rust, just like your example for React or how it's done in Angular. If the lack of a common type is the problem, you can use "dyn Component" which should work as a common trait for all components. I'd appreciate if you could elaborate a bit on this, because the way it's explained in the video might misinform people.
Same. I don't get how rust being different is harder...
Hey! Thanks for asking. If you want more technical details and code snippets, check our our written blog here:
www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard
@@warpdotdev thank you a lot for clarifying!! The article explains more clearly the problem, and even addressed possible solutions. Coding in Rust is indeed challenging after years of the Java way of OO in the majority of OO languages, while many frameworks do exactly what is described in the article (mutate the base class property for example), many would say it's a bad approach of doing things, and while there are workarounds for that in Rust, I don't think it'd be idiomatic. Awesome work on this!
You were a lot more polite than I think I would've been. Was about to point out that class hierarchy is a different concept to the tree like DOM structure react uses. You could implement such a tree like structure in Rust but admittedly there still are some somewhat unwieldy aspects to that due to how borrowing and ownership works in rust (in all likelihood you'll struggle to create a tree which you can modify easily and safely)
We could also build the UI with Raylib. Doesn't mean we should
Fantastic video. I’m not sure I fully followed everything, but I think that’s mostly on me. Do you think the issues you raise are those that UI developers have to contend with or just framework developers? I feel like procedural macros fill in some of the gap left by the lack of inheritance
probably a stupid question but why not use something else to build the ui and use rust for everything else ?
Not a stupid question!
Maybe the video is trying showcase doing full stack with only Rust.
How is writing GUI libraries in Rust more difficult than writing them in plain C? Most GUI libraries were written originally in C, not even in C++, and in C you don't have any OOP.
Anything OOP can do, traits can do better.
The mutability thing is not really a problem in Rust.
Problems with references and the borrow checker? Use smart pointers. Accessing smart pointers is very performant, like accessing references (without optimizations).
Iced is amazing, but still lacks many features.
Are a learner? IGNORE THIS VIDEO. Sorry but this video is completely wrong on several different levels. Inheritance is NOT needed for tree-like structures. Borderline propaganda-like. Who fact-checked this?
As a mathematician I come from c++, python (ML and DL) . Love rust just because ML and DL will need to be productionised at some point.
Unfortunately Rust Cuda is a bit lacking right now right? Do you know of any good projects that are interfacing with GPUs better?
The video is much better than the catchy title suggest
I wouldn't want to create a ui in rust, just a backend that returns json data, and I would delegate the front-end to any framework of your choice, React, Vue, Astro, Svelte, Flutter, you name it
this is what tauri does
web is only one kind of GUI
I had amazing experience building UI PoCs in Rust
- Ratatui for TUIs
- Leptos for WASM webdev
- bevy for ECS WGPU
Found your channel from coding with Lewis and I subscribed 🙌
The quality of video is 🔥
The knowledge given is 🔥
Thanks and bring more content like this
Bhai ye uski kuch lgti kya editing quite similar h ?
@@aryanshaw616 baat toh hai
Kya malum
So glad to hear this. Thank you!
Bevy and egui work pretty well.
Can you elaborate more on the Entity Component Structure method? What sort of GUI library for Rust does this? Did you have to write up your own?
If so does this mean other people writing Rust GUI should stick to the Elm-inspired libraries like Iced?
Bevy does. And you can do GUI in bevy without it needing to be a game...
Rust probably has more object-oriented features than your average Java clone. There are traits (powerful interfaces) instead of abstract classes, and "inheritance" is achieved through them; that is, every struct that implements a trait X de facto "inherits" it so it can be dynamically dispatched to a trait X object. It's really just a more recent and flexible approach.
If Rust doesn't support inheritance, then it's not an OOP language, not based on the textbook definition
You can do a lot more in rust than is apparent right out of the box. I bet you could theoretically do classes with inheritance using macros and you can use data structure with interior mutability as mentioned in the video or if you really want to you could “unsafe{}” it all and build your own model on top of that. You could even implement a garbage collector if you really wanted to.
It’s just that rust can give you some nice guarantees if you figure out how to do things according to the safe borrow rules, and to be honest, you might have to do a lot of work to get some of those other things going, on par with designing your own programming language. To be fair, gui libraries are almost that anyway, with how much terminology is required to reason about them.
There is a lot of experimentation going on in the gui space currently and it’s very fun to follow.
Even if it might be worth while to wait a bit before betting on rust gui if you want to do anything really serious, I don’t think things will stay that way for long.
The thing is that macros are really difficult to use in my opinion. They're best left as "magic" that the programmer doesn't have to think about. What you're proposing is can only work with heavy use of macros and traits, some of the hardest things in the language.
@@user-uf4rx5ih3v I think I agree. (Guessing you refer to the part about classes and inheritance). I don’t recall the whole context of why I wrote the comment.
Using macros can be easy, it can be hard. It depends on the macro. Writing simple ones is quite easy but requires a slightly different skill than using them. Writing macros that would do classes and inheritance… would take some work for sure.
I’m not advocating that everyone and their grandma should do this on their own in their projects. I’m probably not advocating that people should do it at all.
But just in principle if someone does write some set of macros that allow code that works like classes with inheritance, you could just add that library to your project and use the macros. Maybe there is a design that would make the user experience easy. At least as easy as the notion of classes and inheritance, which maybe isn’t simple in itself.
I’m not advocating this. It might be a terrible idea. Probably is.
You can tell me if it sounds like we agree. 👍
I agree overall, most of the time and energy is spent on making Rust a good backend or systems programming language instead of a good front end language. Rust feels underdeveloped in this regard
I think web assembly is also a bottleneck for this. Although in my opinion leptos and yew are also nice flavours if you know solid or react/next. We might get a really nice full stack solution from Rust.
Meanwhile the tooling for the frontend is still being innovated on through Rust at the moment.
@@BboyKeny Thumbs up for mentioning Leptos!
I guess I'm just missing the point. If you want to build a user-mode app with a GUI, you use C# or . Why would you even consider Rust or C or C++? I mean, I guess if you're writing code for a super resource-constrained system, but that's a pretty specialized niche.
Microsoft is using Rust for what it's best at: system level programming. They're doing Azure development in Rust, as well as re-writing some of the Windows system binaries in Rust. And if a developer doesn't want to worry about memory management, they have no business writing a device driver or a kernel binary.
This just seems like a moot point. It's addressing a straw-man scenario. Or, I guess I should allow for the possibility that the world is a weird place, and there are strange people who do inexplicable things. Are there really people that voluntarily choose to write GUI apps in Rust? What's their motivation? The extra performance simply doesn't matter, at all. On the other hand, is there anyone seriously arguing that Rust isn't a very valid, and perhaps even objectively correct, choice for systems level programming? I mean, I did my share of kernel development in C 25+ years ago, and to this day it's the language that I am most comfortable in, but surely even the most die-hard C or C++ developer would allow that Rust is at least a nice option?
I want everything written in rust just so we can say it was written in rust
Why is Warp, a terminal, proprietary!?
Honestly I'm not building UI myself. Using Bevy's ui for ui and egui for debug ui tools.
I subscribed because the thumbs up button went all sparkly, not because it's the best sales pitch for rust I've heard to date.
SwiftUI is all built with structs. I imagine you could do something similar in rust.
ID is the short form of identity. It's ironic that identity ID is used in warp at 8:10 that literally means Identity Identity 😅
It is almost as the person in this video doesn't know object oriented programming. It also looks like it doesn't understand how to handle memory allocation.
We're evaluating Rust as a possibility in modernizing a huge CLI system written in C and TCL. (It is very very old). So far I've found it to be unfamiliar and difficult. It is not really OO and not really functional. It has no garbage collection. It has very high interest among developers for some reason and is the reason we are considering it because we could more easily attract top software engineers. (Our team is entirely made up of 60ish year olds)
"for some reason" lol ... I'm trying to figure out the hype around Rust as well. I think it's an ego "bragging rights" thing
5:28 What safety issues are you talking about?
Good question! We talk about some of the safety concerns of using interior mutability in our blog here:
www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard
🎯 Key Takeaways for quick navigation:
00:31 🧐 Building a graphical user interface (GUI) in Rust is challenging due to Rust's unique features like ownership and mutability rules.
03:44 🔄 Rust's lack of object-oriented programming makes it difficult to create a top-level component that controls a GUI tree, unlike languages like React.
06:51 🧠 One solution for Rust GUI development is adopting the ELM architecture, which consists of model, view, and update, or using an entity component system (ECS) architecture.
08:20 🌐 In Warp, they implement an ECS-style approach with a system that owns components and maps their relationships, providing a way to create a GUI tree without relying on inheritance.
Made with HARPA AI
Are we gui yet? Close enough...
It seems the entire Rust community is using reverse psychology to up their views. Seriously, is there anything straightforward about Rust? Anything at all?
what is your problem with rust?
Wanted to ask, what do you use to create your videos? (this one looks very cool, congratz)
Am already learning Rust . It’s hard but worth it . Am already intermediate
Like the explanation of OOP in UI rendering
Hope the animation helped 👍
Sounds like a trait is a Oo interface, or abstract class.
Tauri isnt to bad for Devs, coming from JS background. I have focus to Tauri with Svelte, as it seems to me quite all in one thing to me. If you do perhaps know like QT for C++. I bet, Rust does have something similar. However, I would not blame Rust for being not good for UI, as it probably offers to many confusing ways to do stuff, if you think in a monolith. Even your MVC approach is unsure to me, as it might lead to blowing up the code.
Both pleasant to watch and listen, and most of all it's spot on topic
With traits , I don’t need abstract classes and inheritance . Other programming languages add bunch of rubbish we don’t even need
Interesting take. I'm new to rust and really enjoy it. Now that I've thouroughly indoctrinated in the crustacean ways. I'm in the mood for some criticism and learning about the pitfalls of rust. Most videos I found were just masked rust propaganda or people that didn't seem to get the point of rust.
Glad to have bumped into this video. This was a breath of fresh air with a well explained and pretty unbiased.
That gets you a like!
And the policeman crab with the moustache earned you a sub.🦀
Currently I am starting to create a VST3 (or maybe Clap) DAW plugin featuring a GUI in Rust.
Hence the HUI framework needs to get the Window context from the DAW via the plugin API.
Once I am able to a non-GUI plugin I will start evaluating GUI frameworks, supposedly starting with ICED.
Js is for the Dom and it should stay that way. Each language has its strengths and rusts' is in threading and memory management, along with a few others from what I know now
I would very much want to hug wichu for a better understanding of this lang u seem so cool like knowing so much about neural formation of this lang 🎉
I am a C++ programmer, but I am looking for ways to implement GUI with an ECS as well. I believe it can be done in a way that code is fast, and API is easy for the user.
Nice video but inheritance and OOP is NOT a cumbersome feature..... we have interfaces (traits) that makes life easy as well. and composition is easier to handle , sure, but just cause other langs offer class inheritance doesn't make it inherently evil
What about Druid framework for Rust GUIs? Are they any good?
Yeah, during the whole video I was just thinking: ".... we can just do it like elm does" I wasn't expecting ecs tho, even though I got interested in rust because of bevy
I think Rust object composition clearly works. You good pointed to some potentially problems, but there are no such problems in a reality.
Omg someone mentioned Elm! I work with Elm quite a headache tbh.
I love your channel and look forward to warp, hope it can have cute background imgs like Windows terminal 🙏
Thank you!
I've seen people write an assembly or another language block inside rust code, maybe GUI is best done that way. Like letting rust do what it does the best, run core code really fast and safe, but separating the GUI to something evil rust shouldn't touch. After all, isn't multiple languages in a project a very common thing already? Like most of the time for web stuff you just have to step into the javascript world to save yourself from more pain.
This video was fantastic in content but visually a little bothersome. Making text hard to read (script vs plain) and then animating it (pulse) and not leaving it on screen long enough really took away from what you were trying to say imo.
It hearkens to a reductive existential contradiction of rust's very safety. Does it mean that one of these methods simply has to "admit" and "embrace" the inevitable? It seems important to choose tools that embrace the inevitable - if it's the inevitable.
The lack of class hierarchy doesn’t mean you can’t organize components in a tree structure, huh? You could easily define a trait with componentDidMount() and similar functions, even a children() function that returns an impl Iterator
I'm using rust a lot in the backend, it's a life saver for me. To build uis for the web though... Not so much.
Also if you need to build desktop apps rust is definitely a good choice to use in the place of c++.
what do you mean? backend = web right?
@@snapcaselled1201 yes
I don't think Rust even comes close to C and C++ in terms of desktop applications for 2024. That situation might change in a decade, or perhaps it will never happen. Just look at the most popular desktop environments for Linux, such as KDE and GNOME; most of them use C and C++ libraries like Qt and GTK. Despite efforts to port these libraries to Rust, it remains-and will likely always be-a second-class language in this domain.
@@christianm4906 people use html, css and js to build UIs, which absolutely sucks, rust still better than that
I love your content, thank you so much for sharing it,
I was thinking how you could look into the camera while talking so people feel like you are talking to them...
How about you create a dead zone in the middle of the monitor. Set up your camera in the dead zone. 😊
ECS outside of gamedev. Is this a dream?
Egui while complex internally is incredibly simple to use and it's pure rust as far as i know.
its runs off wgpu or opengl c++ wrappers i think but it is quite well developed
Thanks for explaining Rust
The command line is a tool that is ripe for change.
So, instead of inheritance you make composition... I think?
i like warp, but why go the route of accounts? just curious
Hey! Good question.
The primary reason is that login allows us to build cloud-oriented features that make the terminal have a concept of “your stuff” and “your team’s stuff” - for example Block Sharing. This is the same reason other collaborative apps like Figma and Github require login - identity is the basis of building cloud-native apps.
That said, we understand the desire to try Warp before logging in, and are exploring product experiences that will allow users to preview Warp before signup.
@@warpdotdev that makes a lot of sense. it was always kind of a turn off for me when i was trying warp, but ill def give it another try now that i know its not JUST telemetry.
thank you very much and keep up the good work
@@rossdafodil7931 Nice! By the way, our telemetry is opt-out. Here's the documentation on how to disable it, if you want.
docs.warp.dev/getting-started/privacy#how-to-disable-telemetry-and-crash-reporting
Why did you build warp with rust?
In short, we chose Rust because of its speed and also its strong developer community (for example, using crates.io for package management was a breeze and our entire team onboarded very quickly with tools like Rustlings).
More importantly, Rust has a pretty extensive platform support--allowing us to write in a single language and then build for Mac, Linux, Windows, and ultimately the web by compiling to WASM.
If you want to read more about how Warp was built, check our our blog here:
www.warp.dev/blog/how-warp-works
Very well informed video!
Glad you think so!
So rust is basically golang without garbage collector?
Excellent video!
I'm learning Dioxus at the moment
The title of this video is misleading. Also React is not a language.
i think you shouldn't swap to camera if you're reading a script, just looks like you have lazy eye, but you're really interesting to listen to otherwise
game dev and web dev is the thing that will propel rust
If I can't build my GUI, I will use a TUI.
What about Zig language?
The biggest issue is no inheritance. This is what happens when you adopt a fad.
"Inheritance is bad because it is okay!"
All this GUI stuff is turning me against Rust.
Well it shouldn’t do. I think part of the problem is that your expectations have been skewed partly due to the misleading title. You should the right tool for the job.
Why'd you use it for UI?
In short, we chose Rust because of its speed and also its strong developer community (for example, using crates.io for package management was a breeze and our entire team onboarded very quickly with tools like Rustlings).
More importantly, Rust has a pretty extensive platform support--allowing us to write in a single language and then build for Mac, Linux, Windows, and ultimately the web by compiling to WASM.
If you want to read more about how Warp was built, check our our blog here:
www.warp.dev/blog/how-warp-works
Why you did not went with Electron? I launched Hyper and on startup it takes same amount of memory as Warp
This is actually the opposite of my expectation about Rust.
The reason why I want to change from kotlin to rust, because I want to use pointer but in a safe way.
Pointer to a structure or class is better than inheritance..
Why do you think placing a pointer to the event loop is inefficient?
Then I guess we need to wait for Iced
After rust I am fighting significantly less with my gf, now I fight with borrow checker
While rust isn’t OOP at least according to some criteria in some definitions, it is at least OP. 😜
We need more sandwiches in modern UI tbh
We agree!
Does this mean you and the warp team regret using Rust to build your app?