made in gimp, with <3

Context for actual rust programmers

I was having massive beef with the rust compiler yesterday, every cargo check takes 20 seconds.

And then look at the three functions below, only one of them are Send, if you know why, please let me know.

(Note: value that is not Send cannot be held across an await point, and Box<dyn Error> is not Send)

async fn one() {
    let res: Result<(), Box<dyn Error>> = do_stuff();
    if let Err(err) = res {
        let content = err.to_string();
        let _ = do_stuff(content).await;
    }
}

async fn two() {
    let res: Result<(), Box<dyn Error>> = do_stuff();
    let content = if let Err(err) = res {
        Some(err.to_string())
    } else {
        None
    };
    drop(res);
    if let Some(content) = content {
        let _ = do_stuff(content).await;
    }
}

async fn three() {
    let content = {
        let res: Result<(), Box<dyn Error>> = do_stuff();
        if let Err(err) = res {
            Some(err.to_string())
        } else {
            None
        }
    };
    if let Some(content) = content {
        let _ = do_stuff(content).await;
    }
}
  • wisha@lemmy.ml
    5·
    5 hours ago

    You are running into the Send Approximation being too conservative. The compiler does not like to see a let binding for a non-Send type and an .await statement in the same scope. It is not (yet) smart enough to know that the non-Send type is already consumed by the time of the .await.

    You’ve already discovered the workaround in your three(). To make it more concise

    async fn four() {
    let content = do_stuff().err().map(|err| err.to_string());
    if let Some(content) = content {
        let _ = do_stuff_2(content).await;
    }
}
    • Ephera@lemmy.mlEnglish
      1·
      4 hours ago

      Yeah, I was gonna say, that might be the root cause.

      In the vast majority of cases, you want Box<dyn Error + Send + Sync>, but folks tend to leave out the Send + Sync, because it looks like additional complexity to them, and because it doesn’t cause problems when they’re not doing async/await.
      It’s better to define a type alias, if you don’t want that long type name everywhere.

  • anyhow2503@lemmy.world
    571·
    13 hours ago

    I get that it’s supposed to be a meme, but aside from the first one these aren’t even rust stereotypes. Is this a meme specifically for people who haven’t used rust, know nothing about rust but have maybe heard that it’s a programming language?

    • nightlily@leminal.spaceEnglish
      12·
      10 hours ago

      Yeah, part of the point of Rust is that it does exactly what you tell it - sometimes to the point of absurdity. No implicit casting for instance.

      • MoffKalast@lemmy.world
        3·
        9 hours ago

        And here I was thinking most of our programming problems come from the thing doing exactly what we told it to, but didn’t quite think the process through enough. Or at all.

    • Fontasia@feddit.nl
      9·
      10 hours ago

      This is for people who learnt C++ in 2008 and refuse to believe that they’ve never fucked up a malloc in their lives

    • communism@lemmy.ml
      5·
      10 hours ago

      I mean Rust is definitely known for long compilation times but yeah otherwise I am not sure how any of this is Rust-specific. Maybe by “doesn’t do what you tell it to do” they mean the borrow checker and strict compile time checks…?

  • [object Object]@sh.itjust.worksEnglish
    712·
    14 hours ago

    Rust output is bad? I feel like it’s one of the best in terms of telling you where you got things wrong. Nix output when you accidentally get infinite recursion is so bad.

    Come to think of it, Nix fits all three better than Rust.