> If you really think that switching language is the main driver to get safe programs [...]
I didn't write that.
> [...] the you are on the list of people replaceable by LLMs.
lol, love a high quality discussion
> Memory management is just a part of the problem.
Sure, then using Rust is a step forward, because that's one less thing you have to worry about. Seat belts don't save all people, but a car equipped with seat belts is - on average - safer than a car without seat belts.
> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
Not the parent commenter, but -- days of week in Polish are a nice example, IMO.
`Środa` means `Wednesday`, but depending on the grammatical case it's going to be translated either to `środa` or `środę` (or five more, but somewhat less likely to appear in UI [1]).
- Next <Wednesday> is 2018-01-03. = Najbliższa <środa> przypada na 2018-01-03.
- This event happens on <Wednesday>. = To zdarzenie ma miejsce w <środę>.
If you mix the variants, it's going to sound very off (but it will be understandable, so there's that).
What's more, days of week have different genders, which affects qualifiers:
- <this> Wednesday = <ta> środa (Wednesday is a "she")
- <this> Monday = <ten> poniedziałek (Monday is a "he")
... together with the grammatical cases affecting the qualifiers:
- <This> Wednesday is crazy. = <Ta> środa jest szalona.
- <This> Thursday is crazy. = <Ten> czwartek jest szalony.
> Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust.
:+1: - it was mostly about "damn, it _feels_ like there should be a better way".
> You might be able to get away with the lock approach and you may even be able to use Rc<RefCell<_>>, which would get a little speed up.
In this particular case that'd be a bit more awkward, because in the actual game the UI is driven by async fn (the rendering itself is sync, of course, but waiting for input is async, and both happen as a part of the same function).
`spawn_local()` could be a good enough solution for that, though.
Sure. But this does not make them proprietary, they work fine with non-Framework laptops as well.