Come on now. You can't blame the compiler when the programmer explicitly told the compiler to not worry about it. There is nothing in existence that can protect against something like that.
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.
I once worked with translating an application to polish, and found out we had to have separate placeholders for "name" for persons (nazwisko) and for things (nazwa).
Which is a simple example why you need context.
All UI frameworks should have a "translate" mode, where all labels and static text can be right-clicked and modified...
> 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.
In that case evaluating the function once is enough to know whether the packet should be let through or not, there's no way to sort of "differentiate" this function, no way to step through it.
But this got me thinking about cases where policy _modifies_ the packet, like:
f(packet, time, ...) = ({ reject, allow }, new-packet)
In this case you'd be looking for a fixed-point, evaluating this function until new-packet = packet (or you exhaust some time and give up). Not sure on the potential utility, though - just a random thought.
Makes sense. Advanced ACL analyzers translate them into first order logic and then use something like Z3 to find the packets that satisfy them but they rarely support the time based ACLs. But those are not used much in practice.
Our dataset wasn't so large as to warrant experimenting with GPUs - `cost(extraCpu) < cost(developerExperimentingWithGpus)` - but the CPU implementation got a lot of love; it was mostly engineering-based work, though ("how to load stuff from the disk effectively", "how to make it multi-threaded" etc.), not math-based work ("if we represented prices using $someFancyStructure, we could ...").
I like when seemingly engineering-oriented problems turn out to be way more approachable once you apply / invent / adjust some math foundations, e.g. like with Feldera (https://sigmodrecord.org/publications/sigmodRecord/2403/pdfs...) - wouldn't figure something like this myself in a hundred years, I'd just probably apply maps on top of caches on top of whatever else I could pile until it works!
I've redacted that part (https://github.com/Patryk27/website/commit/818c27967d7e6332c...), since it doesn't quite make sense if you think about it for longer than a couple seconds; it's 23:02 for me at the moment, maybe the night will bring me a new joke!
but Rust's type system did catch this error - and then author decided it's fine to panic if this error happens
> You won't see Go or Java developers making such strong claims about their preferred languages.
yess no Java developer ever said that OOP will solve world hunger