Also it's really really good. Scarily good tbh. It's making PRs that work and aren't slop-filled and it figures out problems and traces through things in a way a competent engineer would rather than just fucking about.
If you haven't read the Rust Book at least, which is effectively Rust 101, you should not be writing Rust professionally. It has a chapter explaining all of this.
> In production-quality code, most Rustaceans choose expect rather than unwrap and give more context about why the operation is expected to always succeed. That way, if your assumptions are ever proven wrong, you have more information to use in debugging.
I didn't read anything in that section about unwrap/expect that it shouldn't be used in production code. If anything I read it as perfectly acceptable.
A billion alerts in DD/Sentry/whatever saying the exact problem that coincide with the exact graph of failures would probably be helpful if someone looked at them.
The unwrap should be replaced by code that creates enough alerting to make a P0 incidident from their canary deployment immediately.
OR even, the bot code crashing should itself be generating alerts.
Canary deployment would be automatically rolled back until P0 incident resolved.
All of this could probably have happened and contained at their scale in less than a minute as they would likely generate enough "omg the proxy cannot handle its config" alerts off of a deployment of 0.001% near immediately.
Agreed - a big question why the file wasn’t test driven in staging and progressively rolled out. And also what alerting was missing within FL2 that they couldn’t pinpoint the unwrap instantly.
I would say that whilst this is a good top down view, that `.unwrap()` should have been caught at code-review and not allowed. Clippy rule could have saved a lot of money.
That and why the hell wasn't their alerting showing up colossal amount of panics in their bot manager thing?
Yes the lack of observability is really the disturbing bit here. You have panics in a bunch of your core infrastructure, you would expect there to be a big red banner on the dashboard that people look at when they first start troubleshooting an incident.
This is also a pretty good example why having stack traces by default is great. That error could have been immediately understood just from a stack trace and a basic exception message.
Javascript's async/await probably started as a sugar for callbacks (since JS is single-threaded). Many others definitely have that as sugar for whatever threading implementation they have. In C# it's sugar on top of the whole mechanism of structured concurrency.
But I'm mostly talking out of my ass here, since I don't know much about this topic, so everything above is hardly a step above speculation.
There's like 70m of us and most people will just use competitors as opposed to bothering with VPNs. So you're shooting yourself in the foot, financially.
Sucks for people trying to make money then, but that’s hardly a sympathetic case. Sounds like the UK are the ones truly shooting themselves in the foot. Again.
There is a huge amount of UK infra now that is dependant on US companies either directly or indirectly (AWS, Microsoft/Azure). Code, data and infra is locked into US platforms. When US-EAST-1 when down last week, it halted our whole operations at our workplace. Looking at freelancer groups I am part of (whatsapp, slack etc), they had the same experience.
The UK being blocked from the outside won't happen anyway. The large tech giants will just either cut a deal (this already happen with Apple/iCloud), or they will comply with the new acts. The sites that don't comply won't be big enough for anyone to care in normie land and thus there will be no real pressure on the UK gov.
reply