sullyj3 · HackerTrans

1. You can use that style as well. You're free to return early in the error arm of the match, and make use of the Ok value in later straight line code. I've done that in fallible_function in this example:

    fn main() {
        // prints "first call worked"
        if let Ok(i) = fallible_function(Ok(1)) {
            println!("first call worked");
            
        }
    
        // prints "second call failed: FallibleError("error!")"
        if let Err(e) = fallible_function(Err("error!".to_string())) {
            println!("second call failed: {:?}",e);
        }
    
    }

    #[derive(Debug)]
    struct FallibleError(String);

    fn fallible_function(x: Result<i32, String>) -> Result<i32, FallibleError> {
        let y = match x {
            Err(s) => { return Err(FallibleError(s)); },
            Ok(i) => i,
        };
    
        // y now contains the i that was in the Ok.
        // do straight line code with y here
    
        Ok(y)
    }

2. You can create custom errors for a specific function, and put any data that you would have passed to Errorf inside. This way you get the ability to introspect errors to see what went wrong programmatically, and all that data is available for later inspection. Note that we could also have returned a formatted string on error instead of FallibleError exactly like in Go if we wanted to.

Of course, the way you'd write fallible_function if you weren't going out of your way to be verbose would be like this:

    fn fallible_function(x: Result<i32, String>) -> Result<i32, FallibleError> {
        let y = x.map_err(|s| FallibleError(s) )?;
        // y now contains the i that was in the Ok.
        // do straight line code with y here
    
        Ok(y)
    }

Separately, the point of all this is to be able to statically know whether a function can fail or not. We know for a fact that fallible_function can fail. If we write a function

    fn f(x: i32) -> i32 { .. }

We know for a fact it won't fail (unless it panics, but well behaved code should never panic). We don't even have to worry about the possibility of nils getting in there and screwing us up.

sullyj3

5 anni fadiscuss

Yeah, I'm familiar with the ML derivatives, I'm a haskeller, I was musing specifically about imperative languages, because I doubt go programmers would be interested in that much of a switch up.

sullyj3

5 anni fadiscuss

Complexity around memory management and lifetimes is a definite tradeoff that rust makes. A GC imperative language that uses Sum/Product types seems interesting. I guess that would be swift? I'm not familiar.

sullyj3

5 anni fadiscuss

The pain of unwrapping a result type? What's painful about it? If, rather than automatically bubbling it up with ? operator, you want to handle the possibility of failure inline explicitly, it's a simple case of pattern matching that's no more verbose than the `if err != nil` idiom

    match fallible_function() {
        Err(e) => // handle error
        Ok(val) => // do something with val
    }

In this case, you of course don't need to annotate the outer function's type with its possibility of failure. In the case where you use ?, you of course do have to annotate the possibility of failure. However, I think trying to argue that this is more painful as syntactic ceremony than constant nil checks is a non-starter.

It's a strict improvement. You can choose to unwrap on the spot with the same amount of syntactic ceremony as go, except with the compiler checking you've handled the cases. Or, you can do the same thing you were going to do in go anyway, with a single character and a type annotation instead of a stanza.

All this is ignoring the extra power methods like `map`, `map_err`, `map_or_else`, etc, give you.

sullyj3

5 anni fadiscuss

Man, people are really downvoting accurate information just because the truth hurts.

sullyj3

5 anni fadiscuss

The problem with "shut up and calculate" is that sometimes you forget to take things into account. People objecting on grounds of land use elsewhere in this thread have been worried about the size of the infrastructure and mines supporting the manufacture of the solar panels. I have no idea what the ingredients of a solar panel are, or how to calculate W/m^2 after taking area for manufacture into account, but it's plausibly "not quite so many". Then you need to start thinking about batteries for energy storage at night, and so on, and the area increases.

sullyj3

7 anni fadiscuss

> If we had infinite compute today, what steps would you take to build AGI? Does anyone have any good ideas about that?

https://en.wikipedia.org/wiki/AIXI

sullyj3

7 anni fadiscuss

This is all way too close to home, but I legitimately think the time I spent on arch made me more productive on linux machines.

comments