6 ms·

Also “Rewrite it in Rust”. P.S. it’s a joke, guys, but you have to admit it’s at least partially what’s happening

by nlitened 10mo ago

koakuma-chan 10mo ago
No, it has nothing to do with Rust.
- zwnow 10mo ago
  The first one had something to do with Rust :-)
  - kortilla 10mo ago
    Not really. In C or C++ that could have just been a segfault. .unwrap() literally means “I’m not going to handle the error branch of this result, please crash”.
    - mike_hearn 10mo ago
      Indeed, but fortunately there are more languages in the world than Rust and C++. A language that performed decently well and used exceptions systematically (Java, Kotlin, C#) would probably have recovered from a bad data file load.
      - koakuma-chan 10mo ago
        There is nothing that prevents you from recovering from a bad data file load in Rust. The programmer who wrote that code chose to crash.
        mike_hearn 10mo ago
        That's exactly my point. There should be no such thing as choosing to crash if you want reliable software. Choosing to crash is idiomatic in Rust but not in managed languages in which exceptions are the standard way to handle errors.
        koakuma-chan 10mo ago
        I am not a C# guy, but I wrote a lot of Java back in the day, and I can authoritatively tell you that it has so-called "checked exceptions" that the compiler forces you to handle. However, it also has "runtime exceptions" that you are not forced to handle, and they can happen any where and any time. Conceptually, it is the same as error versus panic in Rust. One such runtime exception is the notorious `java.lang.NullPointerException` a/k/a the billion-dollar mistake. So even software in "managed" languages can and does crash, and it is way more likely to do so than software written in Rust, because "managed" languages do not have all the safety features Rust has.
        GoblinSlayer 10mo ago
        When dotnet has an unhandled exception, it terminates with abort.
        mike_hearn 10mo ago
        In practice, programs written in managed languages don't crash in the sense of aborting the entire process. Exceptions are usually caught at the top level (both checked and unchecked) and then logged, usually aborting the whole unit of work. For trapping a bad data load it's as simple as: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file; continuing with old data", e); } This kind of code is common in such codebases and it will catch almost any kind of error (except out of memory errors).
        koakuma-chan 10mo ago
        Here is the Java equivalent of what happened in that Cloudflare Rust code: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file", e); System.exit(1); } So the "bad data load" was trapped, but the programmer decided that either it would never actually occur, or that it is unrecoverable, so it is fine to .unwrap(). It would not be any less idiomatic if, instead of crashing, the programmer decided to implement some kind of recovery mechanism. It is that programmer's fault, and has nothing to do with Rust. Also, if you use general try-catch blocks like that, you don't know if that try-catch block actually needs to be there. Maybe it was needed in the past, but something changed, and it is no longer needed, but it will stay there, because there is no way to know unless you specifically look. Also, you don't even know the exact error types. In Rust, the error type is known in advance.
- gwd 10mo ago
  But it might have something to do with the "rewrite" part: > The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. > Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. > Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. > When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. From https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - windward 10mo ago
    A lot of words for a 'might'. We don't know what caused the downtime.
    - gwd 10mo ago
      Not this time; but the rewrite was certainly implicated in the previous one. They actually had two versions deployed; in response to unexpected configuration file size, the old version degraded gracefully, while the new version failed catastrophically.
      - deleted 10mo ago
        [deleted]
      - 10mo ago
MegaThorx 10mo ago
Did you consider to rewrite your joke in rust?
kenonet 10mo ago
it's never the technology, it's the implementation
rifycombine1 10mo ago
cc: @oncall then trigger pagerduty :)

Also “Rewrite it in Rust”. P.S. it’s a joke, guys, but you have to admit it’s at least partially what’s happening

koakuma-chan 10mo ago

No, it has nothing to do with Rust.

zwnow 10mo ago
The first one had something to do with Rust :-)
- kortilla 10mo ago
  Not really. In C or C++ that could have just been a segfault. .unwrap() literally means “I’m not going to handle the error branch of this result, please crash”.
  - mike_hearn 10mo ago
    Indeed, but fortunately there are more languages in the world than Rust and C++. A language that performed decently well and used exceptions systematically (Java, Kotlin, C#) would probably have recovered from a bad data file load.
    - koakuma-chan 10mo ago
      There is nothing that prevents you from recovering from a bad data file load in Rust. The programmer who wrote that code chose to crash.
      - mike_hearn 10mo ago
        That's exactly my point. There should be no such thing as choosing to crash if you want reliable software. Choosing to crash is idiomatic in Rust but not in managed languages in which exceptions are the standard way to handle errors.
        koakuma-chan 10mo ago
        I am not a C# guy, but I wrote a lot of Java back in the day, and I can authoritatively tell you that it has so-called "checked exceptions" that the compiler forces you to handle. However, it also has "runtime exceptions" that you are not forced to handle, and they can happen any where and any time. Conceptually, it is the same as error versus panic in Rust. One such runtime exception is the notorious `java.lang.NullPointerException` a/k/a the billion-dollar mistake. So even software in "managed" languages can and does crash, and it is way more likely to do so than software written in Rust, because "managed" languages do not have all the safety features Rust has.
        GoblinSlayer 10mo ago
        When dotnet has an unhandled exception, it terminates with abort.
        mike_hearn 10mo ago
        In practice, programs written in managed languages don't crash in the sense of aborting the entire process. Exceptions are usually caught at the top level (both checked and unchecked) and then logged, usually aborting the whole unit of work. For trapping a bad data load it's as simple as: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file; continuing with old data", e); } This kind of code is common in such codebases and it will catch almost any kind of error (except out of memory errors).
        koakuma-chan 10mo ago
        Here is the Java equivalent of what happened in that Cloudflare Rust code: try { data = loadDataFile(); } catch (Exception e) { LOG.error("Failed to load new data file", e); System.exit(1); } So the "bad data load" was trapped, but the programmer decided that either it would never actually occur, or that it is unrecoverable, so it is fine to .unwrap(). It would not be any less idiomatic if, instead of crashing, the programmer decided to implement some kind of recovery mechanism. It is that programmer's fault, and has nothing to do with Rust. Also, if you use general try-catch blocks like that, you don't know if that try-catch block actually needs to be there. Maybe it was needed in the past, but something changed, and it is no longer needed, but it will stay there, because there is no way to know unless you specifically look. Also, you don't even know the exact error types. In Rust, the error type is known in advance.
gwd 10mo ago
But it might have something to do with the "rewrite" part: > The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. > Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. > Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. > When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. From https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- windward 10mo ago
  A lot of words for a 'might'. We don't know what caused the downtime.
  - gwd 10mo ago
    Not this time; but the rewrite was certainly implicated in the previous one. They actually had two versions deployed; in response to unexpected configuration file size, the old version degraded gracefully, while the new version failed catastrophically.
    - deleted 10mo ago
      [deleted]
    - 10mo ago

MegaThorx 10mo ago

Did you consider to rewrite your joke in rust?

kenonet 10mo ago

it's never the technology, it's the implementation

rifycombine1 10mo ago

cc: @oncall then trigger pagerduty :)