4 ms·

The first one had something to do with Rust :-)

• kortilla 11mo 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 11mo 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 11mo 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 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).
        • deleted 11mo ago
          [deleted]
        • kortilla 11mo ago
          unwrap is NOT idiomatic in Rust