Why You Shouldnât Build Your Next App in Rust
āļāļąāļ
- āđāļāļĒāđāļāļĢāđāđāļĄāļ·āđāļ 16 āļ.āļ. 2024
- In this video, we will explore why programming a UI in Rust is so hard and what are some of the possible solutions if you are looking to build an app in the Rust programming language. ðĶðĐâðŧ
You see Rust being talked about EVERYWHERE and for good reason. Something that isn't so obvious is how hard it is to create a User Interface (UI) with it.
We will look at how Rustâs unique memory management model and lack of inheritance make it difficult to use traditional object-oriented programming patterns for UI development. We will also see how some Rust frameworks and libraries are trying to overcome these difficulties by using different approaches, such as functional programming, entity-component-systems, immediate mode GUI, and even the DOM.
If you are interested in learning more about Rust and UI programming, this video is for you!
Written Version ð
www.warp.dev/blog/why-is-buil...
LINKS
-----
Try Warp now for FREE ð bit.ly/warpdotdev
Twitter ðĶ
/ warpdotdev
TikTok ðą
/ warp.dev
TIMESTAMPS
---
0:00 Why Rust is Loved
0:34 What Makes Rust So Unique?
1:45 How UI Programming (Usually) Works
2:46 How Rust Makes This Hard
4:21 Attempting UI Design with Rust
5:34 How We Are Tackling Rust with UI
6:10 ELM Architecture
7:26 Entity Component Structure
7:58 How We Are Building UI
9:03 What Are Your Thoughts?
![[Live āļŠāļ] āļāļēāļĢāļāļāļāļĢāļēāļāļ§āļąāļĨāļŠāļĨāļēāļāļāļīāļāđāļāđāļāļĢāļąāļāļāļēāļĨ āļāļ§āļāļ§āļąāļāļāļĩāđ 16 āļāļĪāļĐāļ āļēāļāļĄ 2567](http://i.ytimg.com/vi/3RndUC0cyV8/mqdefault.jpg)
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?
"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!)
More content like this please, getting fireship vibes here nice balance of educational and fun
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.)
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.
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.
Isn't this a click bait? You didn't explain why we shouldn't use Rust and started explaining all Rust features.
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...
Sorry for nit pick. ReactJS isnât a programming language -> 3:19
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.
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. ð
What about Druid framework for Rust GUIs? Are they any good?
I love your channel and look forward to warp, hope it can have cute background imgs like Windows terminal ð
Thank you!
Both pleasant to watch and listen, and most of all it's spot on topic
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
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.
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 ð
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
Wanted to ask, what do you use to create your videos? (this one looks very cool, congratz)
Thanks for explaining Rust
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?
Omg someone mentioned Elm! I work with Elm quite a headache tbh.
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)
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)?
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!
Like the explanation of OOP in UI rendering
Hope the animation helped ð
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 love your content, thank you so much for sharing it,
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.ðĶ
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.
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.
Very well informed video!
Glad you think so!
Then I guess we need to wait for Iced
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
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 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!
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.
What about Zig language?
Honestly I'm not building UI myself. Using Bevy's ui for ui and egui for debug ui tools.
game dev and web dev is the thing that will propel rust
SwiftUI is all built with structs. I imagine you could do something similar in rust.
Are we gui yet? Close enough...
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 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. ð
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
Why you did not went with Electron? I launched Hyper and on startup it takes same amount of memory as Warp
Would be great to compare it to something modern in web development not something like React that has so many essential issues, where the main one is the whole render model...
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.
I'm learning Dioxus 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?
I want everything written in rust just so we can say it was written in rust
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
Why is Warp, a terminal, proprietary!?
Excellent video!
I only have Web UI experience, mostly in angular 7-15. Flexibility is the main thing to get from a frame work. Ive worked with symfony/ twig, laravel/ blade, alpineJS, and xamarin.
I like a framework to handle routing, navigation, etc. But in the end vanilla JS with JSDocs is just best for DOM manipulation. As much as Javascript drives me insane, I always get to a point to where I need plain 'ol Javascript to accomplish something special. If you want a custom ckeditor, then you still have use vanilla JS. Angular 15 compiling to JS still isn't perfect. I'm eyeing Phoenix + AlpineJS for my next project.
So, instead of inheritance you make composition... I think?
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
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.
I think Rust object composition clearly works. You good pointed to some potentially problems, but there are no such problems in a reality.
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
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
Thanks teacherðŪðģ
No problem!
After rust I am fighting significantly less with my gf, now I fight with borrow checker
We could also build the UI with Raylib. Doesn't mean we should
Great video.
Thanks!
What I got from this video, is that if you try to do things the way you did them in React, you'll have a bad time. If you do them the way Rust wants you to, you'll have a good time.
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.
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.
The video is much better than the catchy title suggest
ECS outside of gamedev. Is this a dream?
The command line is a tool that is ripe for change.
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)
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
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
So rust is basically golang without garbage collector?
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
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.
The title of this video is misleading. Also React is not a language.
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?
Why donât you guys open source your GUI
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.
I've been attempting to find compelling reasons to learn Rust, but it seems to be a challenging programming language in many practical aspects. It will likely be another unsuccessful effort to replace C and C++.
The biggest issue is no inheritance. This is what happens when you adopt a fad.
"Inheritance is bad because it is okay!"
I don't think some of the characterizations stated here are true about Rust, and even the implications about programming in general are a little skewed. Rust not being "OOP" is quite far from accurate as it is about as OOP as C++ and Java meaningfully are -- which is to say that programmers who know true OOP know that even C++ and Java don't even qualify. Needing to use another paradigm that isn't "in vogue" with current frameworks shouldn't be considered a bad thing for a software engineer, it is just a different way of modeling the problem. ELM architecture pretty much seems like MVC to me, but I'm far from a real UI dev. ECS is absolutely an approach software engineers should know if they are writing applications where performance matters -- and hint: performance pretty much always matters. The only question is 1) if your company is wise enough to look at CPU/memory costs for servers and know you're leaving a ton of it on the table, or 2) if you have competing (client) software and customers will see how much slower and memory demanding your application runs versus another.
ECS is very well used in game development as the way "OOP" has made a lot of engineers think about managing data (and indirectly memory) is actually very terribly inefficient when you have multiple subsystems working with the same "object" in your OOP mind, but in reality, the game's subsystems only need to see what they want to see. What I mean is, your game logic has an understand of an entity in the world in terms of gameplay logic and collision detection; the graphics rendering system only cares about the graphics data associated with the object; the sound system only cares about the sound data associated with the object; maybe the netcode doesn't give a crap about the object etc etc. Rather than have a single object "manage" all of it's own stuff as if should maintain all of those references, it's existence is actually defined through those subsystems understanding the association of an identity to the subsystem encapsulated (managed) data. In otherwords, the "Sonic" sprite doesn't reference the fact that it is drawn with "sonic.png," it exists with global ID 112233, and references texture ID 55667 which the graphics resource manager knows was loaded from file "sonic.png" and if you opened in an image editor, you would see the Sonic sprite. It's a classic newbie approach to think that a gameobject "subclass" needs to exist for Sonic, and somewhere in that source code, you'll read the fact that it uses texture "sonic.png." You can make a small game with that approach, but at some level of scale, you'll quickly run into a class explosion and realize how much you're repeating yourself. ECS is also beneficial because it's SoA rather than AoS -- that is, structure of arrays rather than array of structures. When your graphics system needs to rip through 10k objects out of 100k global objects and render those that are visibly relevant, better that it actually runs through an array of 10k relevant objects, than 100k objects through "polymorphism" and 90k objects just have a do nothing render()/draw() method. That's 90k bounces around in memory and your CPU cache is just constantly being trashed.
The real reason Rust isn't a great langauge today for web GUIs is because it simply isn't mature yet. Javascript pretty much exists soley for the purpose of web UI dev and has been for decades and Rust is just arriving. Rust may not even the best use case for front end stuff, but as a general programming language people would like to prove it so projects don't have so much language + tooling mixing requiring too much knowledge spread for a dev team. Plus it has other benefits, that may pay off in the long run if the up front isn't too high.
Ok. Now Let's Get Rusty. ð
If I can't build my GUI, I will use a TUI.
cool video
Thanks!
sudo make me a sammich UI object
While rust isnât OOP at least according to some criteria in some definitions, it is at least OP. ð
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
ðŊ 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
AI will replace decelopers anyway
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?
Subject is so confusing.
ohh great open source project!
wait a second...and I am out