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