Hacker News Reader

> 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).

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.)

In GUI style code you often use closures which have circular dependencies. E.g. button points to the closure (for its event handler), closure points back to the button (e.g. change color of the button upon press).

Obviously you can do this differently, but it makes everything less ergonomic for the programmer.

- "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.

> 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.