4 ms·

This sort of Monday morning quarterbacking is pointless and only serves as a way for random bloggers to try to grab credit without actually doing or creating an

This sort of Monday morning quarterbacking is pointless and only serves as a way for random bloggers to try to grab credit without actually doing or creating any value.

nmoura 11mo ago
I disagree. I learnt good stuff from this article and it’s enough.
- locknitpicker 11mo ago
  > I disagree. I learnt good stuff from this article and it’s enough. That's perfectly fine. It's also besides the point though. You can learn without reading random people online cynically shit talking others as a self promotion strategy. This is junior dev energy manifesting junior level understanding of the whole problem domain. There's not a lot to learn from claims that boil down to "don't have bugs".
  - rvnx 11mo ago
    It's very similar to LinkedIn posts, where everybody seems to know better than the people actually running the platforms.
  - alpinisme 11mo ago
    Not commenting on the quality of this post but occasional writing that responds to an event provides a good opportunity to share thoughts that wouldn’t otherwise reach an audience. If you post advice without a concrete scenario you’re responding to, it’s both less tangible for your audience and less likely to find an audience when it’s easier to shrug off (or put off).
  - galleywest200 11mo ago
    > You can learn without reading random people online Somebody has to write something in the first place for one to learn from it, even if the writing is disagreeable.
    - locknitpicker 11mo ago
      You failed to cite the comment you were replying to. The comment is: > You can learn without reading random people online cynically shit talking others as a self promotion strategy.
  - engineeringwoke 11mo ago
    I laughed out loud when he said Cloudflare should have formally verified its systems.
    - DrSusanCalvin 11mo ago
      Not to single you out in particular, but I see this sentiment among programmers a lot and to me it's akin to a structural engineer saying "I laughed out loud when he said they should analyze the forces in the bridge".
      - engineeringwoke 11mo ago
        You can't formally verify anything that uses consensus, which is the backbone of the entire web. It's a complete non-starter.
        DrSusanCalvin 11mo ago
        Care to elaborate? Perhaps the tools to do this in practice aren't there (which just shows how young the field of software "engineering" really is), but what consensus are you talking about and how is it an obstacle to verifying code? Most of the web follows standards and protocols, which actually sort of a prerequisite for communications across different systems...
        engineeringwoke 11mo ago
        Basically the modern web uses orchestration, for pretty much everything. Usually Kubernetes is doing that. Theoretically protocols like RAFT are formally verifiable, but their implementations in orchestration tools like etcd have not been, and I would go so far as to say that that is an impossible task. Therefore, the entire exercise is kind of silly.
        DrSusanCalvin 11mo ago
        Thanks, interesting. However, that just seems like a protocol like any other, with no real reason why you "can't" formally verify it. Is there something special about a consensus algorithm / protocol that makes it any more difficult to verify than any other algorithm which doesn't yet have a formally verified implementation? Edit: https://link.springer.com/chapter/10.1007/978-3-319-48989-6_8 https://link.springer.com/chapter/10.1007/978-3-319-48989-6_...
  - DrSusanCalvin 11mo ago
    This article actually explains how this bug in particular could have been avoided. Sure you may not consider his approach realistic, but it's not at all saying "don't have bugs". In fact, not having formal verification or similar tooling in place, would be more like saying "just don't write buggy code".
    - locknitpicker 11mo ago
      > This article actually explains how this bug in particular could have been avoided. Not really. The article is a textbook example of hindsight bias. It's a simplistic analysis of a far more complex problem that goes over the blogger's head, and results in a string of simplistic assertions that fail to address any of the issues. Read up on the definition of monday morning quarterback.
      - DrSusanCalvin 11mo ago
        Read up on the value of snarky and dismissive comments spouting simplistic cliches.
- oivey 11mo ago
  What did you learn? The suggestions in the post seem pretty shallow and non-actionable.
echelon 11mo ago
Like your comment? j/k :) I'm using this incident to draw attention to Rust's panic behavior. Rust could use additional language features to help us write mostly panic-free* code and statically catch even transitive dependencies that might subject us to unnecessary panics. We've been talking about it on our team and to other Rust folks, and I think it's worth building a proposal around. Rust should have a way to statically guarantee this never happens. Opt-in at first, but eventually the default. * with the exception of malloc failures, etc.
- tracker1 11mo ago
  It's already in the box... there's a bunch of options from unwrap_or, etc... to actually checking the error result and dealing with it cleanly... that's not what happened. Not to mention the possibility of just bumping up through Result<> chaining with an app specific error model. The author chose neither... likely because they want the app to crash/reload from an external service. This is often the best approach to an indeterminate or unusable state/configuration.
  - echelon 11mo ago
    > This is often the best approach to an indeterminate or unusable state/configuration. The engineers had more semantic tools at their disposal for this than a bare `unwrap()`. This was a systems failure. A better set of tools in Rust would have helped mitigate some of the blow. `unwrap()` is from pre-1.0 Rust, before many of the type system-enabled error safety features existed. And certainly before many of the idiomatic syntactic sugars were put into place. I posted in another thread that Rust should grow annotation features to allow us to statically rid or minimize our codebase of panic behavior. Outside of malloc failures, we should be able to constrain or rid large classes of them with something like this: panic fn my_panicky_function() { None.unwrap(); // NB: `unwrap()` is also marked `panic` in stdlib } fn my_safe_function() { // with a certain compiler or Crates flag, this would fail to compile // as my_safe_function isn't annotated as `panic` my_panicky_function() } Obviously just an idea, but something like this would be nice. We should be able to do more than just linting, and we should have tools that guarantee transitive dependencies can't blow off our feet with panic shotguns. In any case, until something is done, this is not the last time we'll hear unwrap() horror stories.
udev4096 11mo ago
Backdooring the internet is certainly a productive venture!
notepad0x90 11mo ago
You may have missed the point of HN.
pas 11mo ago
pointing out that the basics matter is a valuable insight if this comes with the side-effect of some random blogger getting "easy" credit then so be it the same thing happens in economics, where the bitter lessons have to be learned again and again, and nowadays in politics (and even in ethics) too and of course here people very correctly immediately started talking about the trade-offs involved in making sure that these aforementioned basics are really taken care of, and whether are there low-hanging fruits (does having a better DB schema provide enough benefit for it to worth it? or do you need to couple it with this or that compiler too? but isn't that simply too much? when the critical infrastructure provider should transition to the mindset that most people expect from a critical infrastructure provider? and so on...) whereas in ethics (and intersectional politics) for example there's an unfortunate bitter denial of trade offs

This sort of Monday morning quarterbacking is pointless and only serves as a way for random bloggers to try to grab credit without actually doing or creating any value.

nmoura 11mo ago

I disagree. I learnt good stuff from this article and it’s enough.

locknitpicker 11mo ago
> I disagree. I learnt good stuff from this article and it’s enough. That's perfectly fine. It's also besides the point though. You can learn without reading random people online cynically shit talking others as a self promotion strategy. This is junior dev energy manifesting junior level understanding of the whole problem domain. There's not a lot to learn from claims that boil down to "don't have bugs".
- rvnx 11mo ago
  It's very similar to LinkedIn posts, where everybody seems to know better than the people actually running the platforms.
- alpinisme 11mo ago
  Not commenting on the quality of this post but occasional writing that responds to an event provides a good opportunity to share thoughts that wouldn’t otherwise reach an audience. If you post advice without a concrete scenario you’re responding to, it’s both less tangible for your audience and less likely to find an audience when it’s easier to shrug off (or put off).
- galleywest200 11mo ago
  > You can learn without reading random people online Somebody has to write something in the first place for one to learn from it, even if the writing is disagreeable.
  - locknitpicker 11mo ago
    You failed to cite the comment you were replying to. The comment is: > You can learn without reading random people online cynically shit talking others as a self promotion strategy.
- engineeringwoke 11mo ago
  I laughed out loud when he said Cloudflare should have formally verified its systems.
  - DrSusanCalvin 11mo ago
    Not to single you out in particular, but I see this sentiment among programmers a lot and to me it's akin to a structural engineer saying "I laughed out loud when he said they should analyze the forces in the bridge".
    - engineeringwoke 11mo ago
      You can't formally verify anything that uses consensus, which is the backbone of the entire web. It's a complete non-starter.
      - DrSusanCalvin 11mo ago
        Care to elaborate? Perhaps the tools to do this in practice aren't there (which just shows how young the field of software "engineering" really is), but what consensus are you talking about and how is it an obstacle to verifying code? Most of the web follows standards and protocols, which actually sort of a prerequisite for communications across different systems...
        engineeringwoke 11mo ago
        Basically the modern web uses orchestration, for pretty much everything. Usually Kubernetes is doing that. Theoretically protocols like RAFT are formally verifiable, but their implementations in orchestration tools like etcd have not been, and I would go so far as to say that that is an impossible task. Therefore, the entire exercise is kind of silly.
        DrSusanCalvin 11mo ago
        Thanks, interesting. However, that just seems like a protocol like any other, with no real reason why you "can't" formally verify it. Is there something special about a consensus algorithm / protocol that makes it any more difficult to verify than any other algorithm which doesn't yet have a formally verified implementation? Edit: https://link.springer.com/chapter/10.1007/978-3-319-48989-6_8 https://link.springer.com/chapter/10.1007/978-3-319-48989-6_...
- DrSusanCalvin 11mo ago
  This article actually explains how this bug in particular could have been avoided. Sure you may not consider his approach realistic, but it's not at all saying "don't have bugs". In fact, not having formal verification or similar tooling in place, would be more like saying "just don't write buggy code".
  - locknitpicker 11mo ago
    > This article actually explains how this bug in particular could have been avoided. Not really. The article is a textbook example of hindsight bias. It's a simplistic analysis of a far more complex problem that goes over the blogger's head, and results in a string of simplistic assertions that fail to address any of the issues. Read up on the definition of monday morning quarterback.
    - DrSusanCalvin 11mo ago
      Read up on the value of snarky and dismissive comments spouting simplistic cliches.
oivey 11mo ago
What did you learn? The suggestions in the post seem pretty shallow and non-actionable.

echelon 11mo ago

Like your comment? j/k :) I'm using this incident to draw attention to Rust's panic behavior. Rust could use additional language features to help us write mostly panic-free* code and statically catch even transitive dependencies that might subject us to unnecessary panics. We've been talking about it on our team and to other Rust folks, and I think it's worth building a proposal around. Rust should have a way to statically guarantee this never happens. Opt-in at first, but eventually the default. * with the exception of malloc failures, etc.

tracker1 11mo ago
It's already in the box... there's a bunch of options from unwrap_or, etc... to actually checking the error result and dealing with it cleanly... that's not what happened. Not to mention the possibility of just bumping up through Result<> chaining with an app specific error model. The author chose neither... likely because they want the app to crash/reload from an external service. This is often the best approach to an indeterminate or unusable state/configuration.
- echelon 11mo ago
  > This is often the best approach to an indeterminate or unusable state/configuration. The engineers had more semantic tools at their disposal for this than a bare `unwrap()`. This was a systems failure. A better set of tools in Rust would have helped mitigate some of the blow. `unwrap()` is from pre-1.0 Rust, before many of the type system-enabled error safety features existed. And certainly before many of the idiomatic syntactic sugars were put into place. I posted in another thread that Rust should grow annotation features to allow us to statically rid or minimize our codebase of panic behavior. Outside of malloc failures, we should be able to constrain or rid large classes of them with something like this: panic fn my_panicky_function() { None.unwrap(); // NB: `unwrap()` is also marked `panic` in stdlib } fn my_safe_function() { // with a certain compiler or Crates flag, this would fail to compile // as my_safe_function isn't annotated as `panic` my_panicky_function() } Obviously just an idea, but something like this would be nice. We should be able to do more than just linting, and we should have tools that guarantee transitive dependencies can't blow off our feet with panic shotguns. In any case, until something is done, this is not the last time we'll hear unwrap() horror stories.

udev4096 11mo ago

Backdooring the internet is certainly a productive venture!

notepad0x90 11mo ago

You may have missed the point of HN.

pas 11mo ago

pointing out that the basics matter is a valuable insight if this comes with the side-effect of some random blogger getting "easy" credit then so be it the same thing happens in economics, where the bitter lessons have to be learned again and again, and nowadays in politics (and even in ethics) too and of course here people very correctly immediately started talking about the trade-offs involved in making sure that these aforementioned basics are really taken care of, and whether are there low-hanging fruits (does having a better DB schema provide enough benefit for it to worth it? or do you need to couple it with this or that compiler too? but isn't that simply too much? when the critical infrastructure provider should transition to the mindset that most people expect from a critical infrastructure provider? and so on...) whereas in ethics (and intersectional politics) for example there's an unfortunate bitter denial of trade offs