If you're following a 4-digit number of accounts, your model of social media use is emphatically Not For Me but I can also totally understand it. If you're following a 5+ digit number of accounts... It's just not gonna work out I'm afraid

you just made me check and i found a 6-digit following account on my followers list

i asked chatgpt to try and it gave me

```
\mathbin{\mathbin{\small\raisebox{0.2ex}{$\frown$}}}
```

in one of the rules, so i'm not sure this will work as well as i'd hoped

(8/4) sure, it _wasn't_ actually impossible (as we all found out), but i reject the idea that "handling the error gracefully" would have predicted the possibility of *their own, trusted config data* overrunning its buffer

(7/4) what i expect would end up happening is that some engineer goes to their boss to say "hey so i have this Err(buffer sucks) what do i do", they'd have a meeting concluding "yeah this is impossible" and letting the service fail

(6/4) it's still not clear to me that this error was recoverable in the first place, so at best, what likely would have happened at the periphery is "log the failure and retry", which still would have crashed the internet (because the service still wouldn't be available!)

(5/4) the other argument i've seen advanced is that propagating the error outwards *forces* the engineers to think about the failure cases more explicitly

i am more sympathetic to this view, but still don't think it would have actually saved them

Suffice to say that no, I do not believe that the `unwrap` was the problem. It's arguable whether it was better to let [huge %age of the internet] fail fast vs "proceeding with an overrun buffer" like C++ would have done, but the problem was long before that `.unwrap` got hit.

this was a _config error_, so it's most likely failing in startup anyway!

so sure, you've excised `unwrap` from your fancy service that hot-reloads configs and now get to spam the logs repeatedly as you (checks notes) still can't run due to bad config 4/

and i know enough about these kinds of Big Systems to know that "just allocate more on failure 4head" isn't a good idea

so sure, propagate the error all the way out. it's unclear whether the FL2 service was supposed to be long-lived (probably?), but even if it was 3/

like, sure, you have validated your `Result` and discovered that it's `Err(buffer too small)` or whatever. now what?

can you recover? not really, not without re-architecting the entire system! remember, the error was that some config file was bigger than its allocation 2/

Can you go into detail? My gut is that students will have a harder time wrapping their head around any proof of Rice's theorem that doesn't reduce from HALT to begin with, even if Rice's theorem is more general.

I prefer the fantasy world version: