> But a few instances were to conditionally set one piece of state whenever another piece of state was changed
That use case is explicitly called out on the "You Might Not Need An Effect" article in the docs (which everyone writing React should read, and arguably was published years too late): https://react.dev/learn/you-might-not-need-an-effect
TLDR:
When updating a useState based on another useState, don't use the first useState at all, just compute it inline. If it's expensive, wrap it in a useMemo.
When updating a useState based on props, call the setter directly from the component function, and React will immediately re-render the component (instead of rendering it, running the effect, and then rendering it again).
Believe me, I've read that essay from start to finish, but as I mentioned, it was in the heat of the moment and I didn't have much time to architect something more proper.
> When updating a useState based on another useState, don't use the first useState at all, just compute it inline. If it's expensive, wrap it in a useMemo.
Well, the problem in this case was that the affected useState was not just a pure function of the useState that caused it to be modified: other actions could modify it as well. (E.g., you have some form state that should get updated whenever a state value somewhere else is changed.)
I believe useReducer is a bit closer to the use case I'm thinking of, but the dispatch functions for that are verbose and unpleasant to write. Presumably ad-hoc closures wrapping the setter functions would be somewhat more lightweight.
> Generally, this can be dealt with via policy and moderation to prevent abusive users from causing outsized load on systems, but these processes take time and can be imperfect.
So it’s a case of the engineers accepting that, however hard they try to moderate, these sorts of cases will crop up and they may as well design their infrastructure to handle them.
> if a peaceful protest were to take place during the talk in question, we will not take action, provided the protest is indeed peaceful and does not disrupt the proceedings
Would staging a sit-in explicitly intended to prevent the booked speaker from speaking be classed as “disrupting the proceedings”?
From an infosec perspective, as long as the queries are encrypted (with proper TLS verification), that angle is covered (though there are other considerations about data sovereignity etc.).
In terms of response time, that's something you'd need to benchmark for your application - though, given most DBaaSes run in the same major cloud providers are your application, it'll either be the same region or go cross-region via their private backbone, so the latency delta should be manageable. Of course if your app is particularly latency-sensitive for the DB that won't work.
Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way? As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.
(And further, assuming arguendo that there was DNS meddling happening but somehow getaddrinfo() was exempt - now the user has one app that behaves differently to all their others, which is worse in every practical sense.)
> Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way?
Nothing, I already acknowledge they have the power to do rootkity things if they wanted to, but I don't consider that likely.
I do consider it likely they might do that kind of a thing at a framework level and try to push most developers to use it.
> As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.
I responded to that as I'm responding here, by pointing out that isn't relevant to the threat model that I've described.
> now the user has one app that behaves differently to all their others, which is worse in every practical sense.
Not if that app actually gets the user to where they actually wanted to go.
Not sure if it's what GP is talking about - but haven't you noticed how many juniors seem to be shooting themselves in the foot with LLMs these days, becoming over-reliant on it and gaining expertise slower?
This is exactly what I'm talking about. Ever since LLMs took over, I've noticed an uptick in my fellow senior developers complain about the quality of work, but I've also seen a huge increase in the poor quality of PRs to open source projects.
Like, normally my primary complaint about LLMs is their copyright violating nature, and how it is hanging everyone who has ever published the output of an LLM out to dry, but unless LLM output improves, I think it may end up being a non-issue: their use will die out, and every AI startup will die, just like all the Alt-coin startups did.
Want to change my mind on LLM quality? Have it produce code so good that I can't tell the difference between an inexperienced developer (the kind that would be hired into a junior role, not the kind that would be hired for an internship) and the output of this thing.
I've noticed the opposite: people who had never even started learning to program who are now getting stuck in because they don't have to wade through six months of weird error messages about missing semicolons to get started.
But I guess I'm talking about complete newbie developers, which is a different category from junior developers.
I have 25+ years experience at this point so I'm pretty far removed from truly understanding how this stuff benefits newcomers!
> In the 2022 engagement, the client’s engineers were enthusiastic about the prospect of a public analysis, and Jepsen was allowed to file public issues against systems including etcd. Following the conclusion of the contract, Jepsen independently completed a written report discussing the behaviors we’d found in etcd. However, Jepsen was unable to secure official permission from the client’s legal department to disclose that the client had funded part of the work. This created an unusual state of affairs: the issues, test suite, and reproduction instructions were all public, but per Jepsen’s ethics policy, the analysis itself could not be published. Jepsen shelved that analysis and it remains unpublished. The present analysis is based on entirely new work and verifies a different software system: jetcd, rather than etcd
At the very real risk of "talk is cheap," my understanding is that is part of why Jepsen publishes the test suites (e.g. https://github.com/jepsen-io/etcd ) so it's not "take my word for it" but rather "lein run test-all" and watch the fireworks. So, a sufficiently motivated actor, say for example one of the deep-pocketed stewards of the Kubernetes project could run the tests themselves
Between my indescribable hatred for etcd and my long-held lust for a pluggable KV backend (https://github.com/kubernetes/kubernetes/issues/1957 et al) it'd be awesome if any provable KV safety violations were finally the evidence required for them to take that request seriously
Having looked at the test suite already, I know enough to know that I don't understand it well enough to be that guy to do this. It's for this reason, I'm personally going to pull out the popcorn and see what happens over the next few weeks.
I'm currently working on a Rust v3 client, and have been reading the Go v3 source code, and the code definitely is hard to follow so I would be unsurprised if there were issues lurking.
I was curious and dug into the Go client code. You linked to the definition of KV – the easiest way to create one is with NewKV [1], which internally creates a RetryKV [2] wrapper around the Client you give it.
RetryKV implements the KV methods by delegating to the underlying client. But before it delegates an immutable request (e.g., range), it sets the request retry policy to repeatable [3].
Retries are implemented with a gRPC interceptor, which checks the retry policy when deciding whether a request should be retried [4].
The Jepsen writeup says a client can retry a request when “the client can prove the first request could never execute, or that the request is idempotent”. In my (cold) read of the code, the Go client stays within those bounds.
For non-idempotent requests, the Go client only retries when it knows the request was never sent in the first place [5]. For idempotent requests, any response with gRPC status unavailable will be retried [6].
Unlike jetcd, the Go client’s retry behavior is safe.
The watch is a simple processing loop that receives and sends on a bi-directional GRPC channel. Leases have a similar loop for keep-alive messages, everything else is quite literally delegated.
I get that it's difficult to translate this 1:1 into Rust without channels and select primitives, but saying it's complex is wild. Try the server-side code for leases ;)
Some lines on the London Underground do use ATO without platform barriers. The driver closes the doors, checks that the platform is clear, then starts the train. ATO takes over until the next station, where the driver watches to make sure there's nobody too close to the edge, ready to slam on the emergency brake.
And https://www.map.signalbox.io/, which tries to interpolate signal locations onto a geographic map (with the expected level of inaccuracy, though still not half-bad)
That use case is explicitly called out on the "You Might Not Need An Effect" article in the docs (which everyone writing React should read, and arguably was published years too late): https://react.dev/learn/you-might-not-need-an-effect
TLDR:
When updating a useState based on another useState, don't use the first useState at all, just compute it inline. If it's expensive, wrap it in a useMemo.
When updating a useState based on props, call the setter directly from the component function, and React will immediately re-render the component (instead of rendering it, running the effect, and then rendering it again).