5 ms·

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 11mo 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 11mo 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 11mo ago
    When dotnet has an unhandled exception, it terminates with abort.
  - mike_hearn 11mo 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 11mo 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.
      - mike_hearn 11mo ago
        Yes, I know. But nobody writes code like that in Java. I don't think I've ever seen it outside of top level code in CLI tools. Never in servers. > It is that programmer's fault, and has nothing to do with Rust. It's Rust's fault. It provides a function in its standard library that's widely used and which aborts the process. There's nothing like that in the stdlibs of Java or .NET > Also, if you use general try-catch blocks like that, you don't know if that try-catch block actually needs to be there. I'm not getting the feeling you've worked on many large codebases in managed languages to be honest? I know you said you did but these patterns and problems you're raising just aren't problems such codebases have. Top level exception handlers are meant to be general, they aren't supposed to be specific to certain kinds of error, they're meant to recover from unpredictable or unknown errors in a general way (e.g. return a 500).
        koakuma-chan 11mo ago
        > It's Rust's fault. It provides a function in its standard library that's widely used and which aborts the process. There's nothing like that in the stdlibs of Java or .NET It is the same as runtime exceptions in Java. In Rust, if you want to have a top-level "exception handler" that catches everything, you can do ::std::panic::catch_unwind(|| { // ... }) In case of Cloudflare, the programmer simply chose to not handle the error. It would have been the same if the code was written in Java. There simply would be no top-level try-catch block.
- deleted 11mo ago
  [deleted]
- kortilla 11mo ago
  unwrap is NOT idiomatic in Rust

mike_hearn 11mo 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 11mo 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 11mo ago
  When dotnet has an unhandled exception, it terminates with abort.
- mike_hearn 11mo 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 11mo 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.
    - mike_hearn 11mo ago
      Yes, I know. But nobody writes code like that in Java. I don't think I've ever seen it outside of top level code in CLI tools. Never in servers. > It is that programmer's fault, and has nothing to do with Rust. It's Rust's fault. It provides a function in its standard library that's widely used and which aborts the process. There's nothing like that in the stdlibs of Java or .NET > Also, if you use general try-catch blocks like that, you don't know if that try-catch block actually needs to be there. I'm not getting the feeling you've worked on many large codebases in managed languages to be honest? I know you said you did but these patterns and problems you're raising just aren't problems such codebases have. Top level exception handlers are meant to be general, they aren't supposed to be specific to certain kinds of error, they're meant to recover from unpredictable or unknown errors in a general way (e.g. return a 500).
      - koakuma-chan 11mo ago
        > It's Rust's fault. It provides a function in its standard library that's widely used and which aborts the process. There's nothing like that in the stdlibs of Java or .NET It is the same as runtime exceptions in Java. In Rust, if you want to have a top-level "exception handler" that catches everything, you can do ::std::panic::catch_unwind(|| { // ... }) In case of Cloudflare, the programmer simply chose to not handle the error. It would have been the same if the code was written in Java. There simply would be no top-level try-catch block.
deleted 11mo ago
[deleted]
kortilla 11mo ago
unwrap is NOT idiomatic in Rust