Looks fun, but Rust is less well suited to UX than other langauges - tree based data structures, a lot of ugly state, event driven, heavily async, and naturally all of the json and other things that come in at that layer don't have 'very nice' libraries.

It does not leverage of Rusts advantages very well at all, and so the extra overhead is hard to justify.

I think there are definitely some key libs that would work well with rust (wgpu is nice!), but the the core language itself would ideally not be Rust.

Obviously - it can be done - and I'm sure it's a lot of fun for some devs - but I think this is fitting the circle into the square hole. (Edit - it's funny saying that because 'fitting the circle into the square hole' is literally like saying 'walkies?' or to a dog, aka 'arise - a problem to be solved!' but I think that is what I'm getting at, like what wags the tail isn't necessarily the best option)

▲

kaoD an hour ago | parent | next [-]

> Rust is less well suited to UX than other langauges - tree based data structures, a lot of ugly state, event driven, heavily async, and naturally all of the json and other things that come in at that layer don't have 'very nice' libraries.

Can you elaborate? I don't see anything there that is hard for Rust per se:

- Tree-based data structures are just the bread and butter of Rust as long as they are not cyclic, but arguably you shouldn't be declaring your UI with cycles at all.

- Ugly state is exactly what Rust was made for. It forces you to tame the ugly state instead of hacking at it and hoping it works.

- Event driven and heavily async are neither a Rust strength nor a weakness (some would say it's actually a strength but IMO there are tradeoffs). Actors and message passing are one of the many patterns that Rust is fantastic at.

- And I don't see how JSON is relevant to UI, but JSON is not only "solved" in Rust but the best ser/de libraries I've ever used are in Rust.

Rust gets cumbersome with hyper-connected or hyper-shared ownership (think e.g. inodes in a filesystem) where you have to sidestep the borrow checker... but UIs are inherently hierarchical.

Yes, Rust doesn't fit the traditional OOP cycle-connected "widget" model where a textbox "knows" about its sibling button, and the button "knows" about its sibling textbox. Turns out that that model sucks, and that's why everyone fled to React and other saner models even without Rust's constraints.

Maybe I'm just biased by the React mindset (unidirectional data flow), but I've never been happy with any other UI paradigm so I consider that an advantage.

▲

ADevWithAnIdea 36 minutes ago | parent | next [-]

> Ugly state is exactly what Rust was made for. It forces you to tame the ugly state instead of hacking at it and hoping it works.

I'm not an expert on GUIs, but my understanding of them is that the ugly state is sort of inherent to GUI applications and you can't tame it. Ie, everything interconnects with everything else and there's not much you can do about that. This sort of inherently pushes you to a big runtime that manages a lot of stuff for you, which is in line with GUIs being rather expensive generally (ultimately you have to render everything to the screen).

	▲	kaoD 26 minutes ago \| parent [-]
		Maybe I can understand better with an actual example? I might just be biased by React's mindset, but I've always considered two-way binding (and any non-unidirectional data flow) a mistake, and it has only brought me pain and sorrow. In other words: the patterns I use outside of Rust are also Rust's happy paths (on paper, maybe I'm just missing something?) (For clarity: I'm talking of userland here. I assume that's what OP meant by "UX" -- I agree with your "big runtime" point, but that's why my RAM is filled by Electron apps.)

▲

bluegatty an hour ago | parent | prev [-]

- "Tree-based data structures are just the bread and butter of Rust." - they are not - they are the opposite of 'bread and butter'. They create nearly impossible problems for borrow checkers. Literally where the borrow checker caps out and can't fulfill it's obligations.

- "shouldn't be declaring your UI with cycles at all." - they are inherently cyclical. Parent/child and handler/emitter relations are very common. You can work around it, but unnaturally.

"Ugly state is exactly what Rust was made for. " - No. Rust forces you into constraints, which have certain paramters.

--> this is the biggest conceit of Rust - that somehow, the 'borrow checker is correct'. It is not. It is a constraint. Having to meet that constraint is in some cases beneficial, but it's mostly just limiting.

The limitation of that constraint and implications is so strong, that it keeps Rust from being mainstream.

- "Event driven and heavily async are neither a Rust strength nor a weakness"

Async in Rust is objectively hard, it's another dimensional of complexity that does not have the same impact in other languages. Asyc does create issues everywhere but not as much as in Rust. Again, another big layer of trickery for not advantage.

- " but JSON is not only "solved" in Rust but the best ser/de libraries I've ever used are in Rust." - then maybe you have never programmed in any other language?

Because the 'best' language for JSON is obviously Javascript/Typescript - and it suites most OO languages extremely well.

The question underlying all of these statements, is why anyone would ever choose Rust in the first place?

Rust brings much greater complexity for no advantage in most cases.

By any objective measure, Rust is just a 'bad choice' for all but a narrow set of things.

I think you have to add both 'developer interest', 'integration with specific libraries' and maybe 'other strategic considerations' in order for Rust to be a rational choice in a lot of cases.

	▲	kaoD 44 minutes ago \| parent [-]
		> Parent/child and handler/emitter relations are very common. You can work around it, but unnaturally. I think this is where we disagree. If your UI data flow is not unidirectional, that's a problem you brought yourself into, Rust or not. For reference: I don't do my UIs in Rust, but the language is not the reason why, and I still use unidirectional data flow even on GC'd languages. > Because the 'best' language for JSON is obviously Javascript/Typescript As a TypeScript fan (it's my main language)... ser/de sucks in TS and IO boundaries are most of my pain points with it. My top 2 things that I miss from Rust are: (1) serde/rkyv (2) affine types. Zod has been great but it's still miles behind a proper ser/de library. And yet I still can't see how JSON is relevant for UIs.

▲

2 hours ago | parent | prev [-]

[deleted]