3 ms·

I’ve been seeing you blazing this trail since the incident and it feels short sighted and reductive. Rust is built on forcing the developer to acknowledge the

I’ve been seeing you blazing this trail since the incident and it feels short sighted and reductive. Rust is built on forcing the developer to acknowledge the complexity of reality. Unwrap acknowledges said complexity with a perfectly valid decision. There are a few warts from early days like indexing and the ”as” operator where the easy path is doing the wrong thing. But unwraps or expects are where Rust shines. Throwing up your hands is a perfectly reasonable response. With your approach, what should Cloudflare have done? Return an error, log it and return a 500 result due to invalid config? They could fail open, but then that opens another enormous can of worms. There simply are no good options. The issue rests upstream where deployments and effects between disparate services needs to be mapped and managed. Which is a truly hard problem, rather than blaming the final piece throwing up its hand when given an invalid config.

echelon 11mo ago
> I’ve been seeing you blazing this trail since the incident and it feels a short sighted and reductive. Why is it inappropriate to be able to statically label the behavior? Maybe I don't want my failure behavior dictated by a downstream dependency or distracted engineer. The subject of how to fail is a big topic and is completely orthogonal to the topic of how can we know about this and shape our outcomes. I would rather the policy be encoded with first class tools rather than engineering guidelines and runbooks. Let me have some additional control at what looks like to me not a great expense. It doesn't feel "safe" to me to assume the engineer meant to do exactly this and all of the upstream systems accounted for it. I would rather the code explicitly declare this in a policy we can enforce, in an AST we can shallowly reason about.
- ViewTrick1002 11mo ago
  How deep do you go? Being forced to label any function that allocates memory with ”panic”? Right now you all the instances where the code can panic are labeled. Grep for unwrap, panic, expect etc. In all my years of professional Rust development I’ve never seen a potential panic pass code review without a discussion. Unless it was trivial like trying to build an invalid Regex from a static string.
  - echelon 11mo ago
    Malloc is fair game. Unwrap, slice access, etc. are not.
    - ViewTrick1002 11mo ago
      And now the endless bikeshedding has begun. Thanks for making abundantly clear how such a feature wouldn’t solve a thing.
      - echelon 11mo ago
        https://news.ycombinator.com/item?id=46060907 https://news.ycombinator.com/item?id=46060907 Copying this so you see it too - The Cloudflare outage was a multi-billion dollar outage. I have personally been involved in multiple hundred million dollar outages at fintechs, so forgive me for being passionate about this. Several of the outages I've been involved in were the result of NPEs or incorrectly processing runtime data. Rust has tools to enforce safety here, but it doesn't have tools to enforce your use of them. If also doesn't have a way to safeguard you from others deciding the behavior for you. There is potentially a very easy set of non-onerous features we could build that allow us to prevent this.
        sfink 11mo ago
        Except that the outage would still have happened without that .unwrap(). So go ahead and build those features, they sound useful, but don't think that they'd save you from a failure like this. As the poster here said, the place to build in features that would have prevented this from happening is the DB schema and queries. 5NF would be onerous overkill here, but it seems reasonable to have some degree of forced normalization for something that could affect this much. (Requiring formal verification of everything involved here would be overkilling the overkill, otoh.)
    - dpark 11mo ago
      So slicing is forbidden in this scheme? But not malloc? This doesn’t seem to be a principled stance on making the language safer. It feels a bit whack-a-mole. “Unwrap is pretty easy to give up. I could live without slicing. Malloc seems hard though. I don’t want to give that up.”

echelon 11mo ago

> I’ve been seeing you blazing this trail since the incident and it feels a short sighted and reductive. Why is it inappropriate to be able to statically label the behavior? Maybe I don't want my failure behavior dictated by a downstream dependency or distracted engineer. The subject of how to fail is a big topic and is completely orthogonal to the topic of how can we know about this and shape our outcomes. I would rather the policy be encoded with first class tools rather than engineering guidelines and runbooks. Let me have some additional control at what looks like to me not a great expense. It doesn't feel "safe" to me to assume the engineer meant to do exactly this and all of the upstream systems accounted for it. I would rather the code explicitly declare this in a policy we can enforce, in an AST we can shallowly reason about.

ViewTrick1002 11mo ago
How deep do you go? Being forced to label any function that allocates memory with ”panic”? Right now you all the instances where the code can panic are labeled. Grep for unwrap, panic, expect etc. In all my years of professional Rust development I’ve never seen a potential panic pass code review without a discussion. Unless it was trivial like trying to build an invalid Regex from a static string.
- echelon 11mo ago
  Malloc is fair game. Unwrap, slice access, etc. are not.
  - ViewTrick1002 11mo ago
    And now the endless bikeshedding has begun. Thanks for making abundantly clear how such a feature wouldn’t solve a thing.
    - echelon 11mo ago
      https://news.ycombinator.com/item?id=46060907 https://news.ycombinator.com/item?id=46060907 Copying this so you see it too - The Cloudflare outage was a multi-billion dollar outage. I have personally been involved in multiple hundred million dollar outages at fintechs, so forgive me for being passionate about this. Several of the outages I've been involved in were the result of NPEs or incorrectly processing runtime data. Rust has tools to enforce safety here, but it doesn't have tools to enforce your use of them. If also doesn't have a way to safeguard you from others deciding the behavior for you. There is potentially a very easy set of non-onerous features we could build that allow us to prevent this.
      - sfink 11mo ago
        Except that the outage would still have happened without that .unwrap(). So go ahead and build those features, they sound useful, but don't think that they'd save you from a failure like this. As the poster here said, the place to build in features that would have prevented this from happening is the DB schema and queries. 5NF would be onerous overkill here, but it seems reasonable to have some degree of forced normalization for something that could affect this much. (Requiring formal verification of everything involved here would be overkilling the overkill, otoh.)
  - dpark 11mo ago
    So slicing is forbidden in this scheme? But not malloc? This doesn’t seem to be a principled stance on making the language safer. It feels a bit whack-a-mole. “Unwrap is pretty easy to give up. I could live without slicing. Malloc seems hard though. I don’t want to give that up.”