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;
    }
}
  • [object Object]@sh.itjust.worksEnglish
    931·
    4 days 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.

      • Ethan@programming.devEnglish
        111·
        3 days ago

        Yes, preferring a language that’s easy to read and therefore easy to maintain over a language like Rust is definitely coping 🙄

        • WhyJiffie@sh.itjust.worksEnglish
          251·
          3 days ago

          preferring Rust over Rust? what do you mean?

          do you think loosely typed python is easy to read and maintain?

            • edinbruh@feddit.itEnglish
              111·
              3 days ago

              Yeah, like, who would ever want to

              stuff1()?.map(stuff2);

              It’s much better to just:

              err, value = stuff1();
if err == nil 
    return err, nil;
if value != nil
    stuff2(value);

              And you might even:

              for a in vec {
    vec[a]
}
              • Ethan@programming.devEnglish
                4·
                3 days ago

                I totally agree, that Go snippet is absolutely more maintainable. Though you forgot the curly braces and the semicolons are unnecessary.

                • AeonFelis@lemmy.world
                  2·
                  3 days ago

                  Though you forgot the curly braces and the semicolons are unnecessary.

                  Yup. These are pretty big issues. But there are also some minor, trivial, purely-preference-based issues - like returning an error if err == nil instead of when it isn’t.

      • bobo@lemmy.ml
        8·
        3 days ago

        random pile of unclear errors

        warning: Git tree ‘/path/to/repo’ is dirty

        • Ephera@lemmy.mlEnglish
          3·
          3 days ago

          Unfortunately, that shows up even when you’ve just modified an existing file, which is not a problem for it.

          And which also happens to be the state my repo is in basically all the time, because I’ll change some setting, then see if it works like I want it to before making a commit…

          • bobo@lemmy.ml
            2·
            3 days ago

            Fortunately, your comment is not relevant at all since I incorrectly posted the warning instead of the explicit error:

            error: Path 'path/to/file' in the repository "/path/to/repo" is not tracked by Git.

            It even gives you

            To make it visible to Nix, run:

git -C "/path/to/repo" add "path/to/file"
            • Ephera@lemmy.mlEnglish
              2·
              3 days ago

              I thought, you posted about the warning, because that’s actually easier to see than the error. Because yeah, it does say what you posted, but it’s in the middle of like 30 lines of other stuff. When I forget to stage a new file, it almost always takes me 5+ seconds to spot what the problem is. 🥲

              • bobo@lemmy.ml
                1·
                3 days ago

                For me there was only 1 line beneath that error, it’s more visible than the warning. Maybe they improved it, or you started reading from the top?

                I just completely forgot about that error because I have an extremely basic config.

                • Ephera@lemmy.mlEnglish
                  1·
                  3 days ago

                  Hmm, that’s interesting. For me, it looks like this:

                  I actually thought, it said somewhere in there, that the file isn’t staged, but apparently not even that (anymore?).

                  You don’t happen to be using Lix or something, do you? I’ve heard that it’s supposed to have better error messages, but I was never sure how much better it might be…

                  Edit: Perhaps I should add that those code locations it shows, are not from my code. Only the modules/terminal/new_file.nix in the second-last line is relevant.

  • anyhow2503@lemmy.world
    721·
    4 days 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?

    • Fontasia@feddit.nl
      16·
      3 days 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

      • limer@lemmy.ml
        2·
        3 days ago

        Hah I learned c++ in the 90s and never felt shame for messing up an allocation.

        I think when this happens, I have a puddle of memory, the spilled ram “lubricates” the pointers, which often rub against each other. The wasted memory acts like oil does to a rusted chain. It’s helping push the program through the finish line.

        Yes, I am having fun here

    • communism@lemmy.ml
      15·
      3 days 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…?

        • anyhow2503@lemmy.world
          2·
          3 days ago

          I was actually wondering if this was supposed to be about a specific problem someone has with rust (not like I haven’t gotten stuck on some weird corner with rust before), but looking at the meme, that seemed unlikely to me. Thanks for the context.

  • wisha@lemmy.ml
    19·
    3 days 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
      6·
      3 days 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.