movq
www.uninformativ.de
 (11w ago)
↳ In-reply-to » Okay, here’s a thing I like about Rust: Returning things as Option and error handling. (Or the more complex Result, but it’s easier to explain with Option.)

@prologic@twtxt.net I’d say: Yes, because in Go it’s easier to ignore errors.

We’re talking about this pattern, right?

f, err := os.Open("filename.ext")
if err != nil {
    log.Fatal(err)
}

Nothing stops you from leaving out the if, right? 🤔

⤋ Read More
movq
www.uninformativ.de
 (11w ago)
↳ In-reply-to » Saw this on Mastodon:

(Of course, if we’re talking about a project you’re doing for a customer and the customer keeps asking for new stuff, then you’re never done, and you have to think ahead and expect changes. Is that what they mean? 🤔)

⤋ Read More
movq
www.uninformativ.de
 (11w ago)

Saw this on Mastodon:

https://racingbunny.com/@mookie/114718466149264471

18 rules of Software Engineering

  1. You will regret complexity when on-call
  2. Stop falling in love with your own code
  3. Everything is a trade-off. There’s no “best” 3. Every line of code you write is a liability 4. Document your decisions and designs
  4. Everyone hates code they didn’t write
  5. Don’t use unnecessary dependencies
  6. Coding standards prevent arguments
  7. Write meaningful commit messages
  8. Don’t ever stop learning new things
  9. Code reviews spread knowledge
  10. Always build for maintainability
  11. Ask for help when you’re stuck
  12. Fix root causes, not symptoms
  13. Software is never completed
  14. Estimates are not promises
  15. Ship early, iterate often
  16. Keep. It. Simple.

Solid list, even though 14 is up for debate in my opinion: Software can be completed. You have a use case / problem, you solve that problem, done. Your software is completed now. There might still be bugs and they should be fixed – but this doesn’t “add” to the program. Don’t use “software is never done” as an excuse to keep adding and adding stuff to your code.

⤋ Read More
movq
www.uninformativ.de
 (11w ago)

Okay, here’s a thing I like about Rust: Returning things as Option and error handling. (Or the more complex Result, but it’s easier to explain with Option.)

fn mydiv(num: f64, denom: f64) -> Option<f64> {
    // (Let’s ignore precision issues for a second.)
    if denom == 0.0 {
        return None;
    } else {
        return Some(num / denom);
    }
}

fn main() {
    // Explicit, verbose version:
    let num: f64 = 123.0;
    let denom: f64 = 456.0;
    let wrapped_res = mydiv(num, denom);
    if wrapped_res.is_some() {
        println!("Unwrapped result: {}", wrapped_res.unwrap());
    }

    // Shorter version using "if let":
    if let Some(res) = mydiv(123.0, 456.0) {
        println!("Here’s a result: {}", res);
    }

    if let Some(res) = mydiv(123.0, 0.0) {
        println!("Huh, we divided by zero? This never happens. {}", res);
    }
}

You can’t divide by zero, so the function returns an “error” in that case. (Option isn’t really used for errors, IIUC, but the basic idea is the same for Result.)

Option is an enum. It can have the value Some or None. In the case of Some, you can attach additional data to the enum. In this case, we are attaching a floating point value.

The caller then has to decide: Is the value None or Some? Did the function succeed or not? If it is Some, the caller can do .unwrap() on this enum to get the inner value (the floating point value). If you do .unwrap() on a None value, the program will panic and die.

The if let version using destructuring is much shorter and, once you got used to it, actually quite nice.

Now the trick is that you must somehow handle these two cases. You must either call something like .unwrap() or do destructuring or something, otherwise you can’t access the attached value at all. As I understand it, it is impossible to just completely ignore error cases. And the compiler enforces it.

(In case of Result, the compiler would warn you if you ignore the return value entirely. So something like doing write() and then ignoring the return value would be caught as well.)

⤋ Read More