The weight/shape of the module will break the USB-C port in short order because it is solely supported by the connector.
For instance, by bumping the spatula hanging off your Mac.
For that matter, USB-C are crap connectors, I don't care how many graphs and BS data you show me stating they're the most reliable connector ever. I do not believe it.
They're the only types of connectors I've seen damaged repeatedly, and the only one with which I've personally experienced damage, and I've been using laptops since before many of you were born.
> 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.
Bugs are not only related to memory and a program cannot be considered safe Just because it got rid of pointers, malloc and free.
If you really think that switching language is the main driver to get safe programs, the you are on the list of people replaceable by LLMs.
Othewise you have to understand that architettural chioces, concurrency, (weak) cryptographic function and user stupidity have a significant impact, no matter what language you use. Memory management is just a part of the problem.
> 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.
Javascript/PCRE/etc regexes have additional features (like backreferences) that give them strictly more computational power than a regular DFA/NFA. (Still not Turing complete though without external control flow to support arbitrary iteration/recursion, like is done here)
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.
My Framework ethernet dongle works perfectly fine with a Mac that I use for work, for instance.