> If you're always doing this, you're always being underpaid by a full level.

This doesn't actually follow, for a variety of reasons, including that jobs have compensation ranges and in a lot of cases the bottom of one is pretty close to, or even below, the top of the previous one.

One of the big reasons that changing companies was good from a compensation perspective was 4 year initial offers. Upleveled job-switches do happen, but from what I've seen they don't usually happen much faster than internal promotions, and often they happen slower!

Many cases that require any kind of cast are this.

The point is that this isn't unique to rust.

Very few organizations need security from state level or similar threats and the infrastructure provider. Most organizations that want secure email don't use any kind of e2ee at all, they just trust Google or Microsoft or whomever.

The few jobs that actually care about this stuff, like journalists, do use signal.

Openwall doesn't get security via pgp, it gets a spam filter.

Under a gold backed economy, things are zero-sum. Under a fiat based economy, they aren't. If your concern is about the problems of a zero-sum system, you should support a lack of scarcity in the money supply.

Not so. It's a lot worse now because before, people just monopolized fixed quantities of gold. If they made bad bets, their gold holdings would shrink.

Now the monopolies aren't over limited quantities of units... They are monopolies over entire money flows with unlimited (and adjustable) quantities of units... People who control these flows can make many bad bets and barely feel a thing. The people who decide the flows don't do so at any expense to themselves; it's the public's money which is printed out of nothing. People like Richard Werner literally proved this after everyone was gaslit about it for over a decade... And now AI is used to spam all reasonable discussions about the system out of view, in spite of all the evidence of dysfunction.

As an extreme example, look at what happened with Jeff Bezos, Bill Gates and their divorces... Lost a lot of units of currency at one point but it barely affected them financially, it's like the money pipelines just adjusted themselves to bring them back to the level they were before.

I mean yes it is unsurprising that people with nearly infinite money are materially impacted by losing half of it.

But neither is at the level they were at before, at least in comparison to the market and economic growth overall.

> Not so. It's a lot worse now because before, people just monopolized fixed quantities of gold. If they made bad bets, their gold holdings would shrink.

Yes, this is precisely the "zero-sum" thing you said is problematic.

Yes. People have complained about the difficulty of Google or Facebook account recovery and how they need to make it easier and more accurate for ages. You could search hn for "password reset" or "lost password" and you'll find tons.

You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies.

If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.

You shouldn't depend on the auth service, just subscribe to it's messages and/or trust your IDP's tokens.

This article, in my interpretation, is about hard dependencies, not soft. Each of your services should have their own view of "the world". If they aren't able to auth/auth a request, it's rejected - as it should be, until they have the required information to accept the request (ie. broadcasted role information and/or an acceptable jwt).

Your comments are the only ones in this comment section that mention retirement.

I mean, Google just isn't participating it seems?

I had a former coworker who moved from the medical device industry to similar-to-cloudflare-web software. While he had some appreciation for the validation and intense QA they did (they didn't use formal methods, just heavy QA and deep specs), it became very clear to him very clearly that those approaches don't work with speed-of-release as a concern (his development cycles were annual, not weekly or daily). And they absolutely don't work in contexts where user-abuse or reactivity are necessary. The contexts are just totally different.

It is perfectly possible to engineer for faster cycles without losing control over what your code can and can not do. It is harder, for sure. But I do not think it is a matter of this absolutely not working, that's black-and-white and it never is black and white, it is always some shade of gray.

For instance: validating a configuration before loading it is fairly standard practice, as are smoke tests and gradual roll-outs. Configuration fuck-ups are fairly common so you engineer with that in mind.