472
submitted 1 week ago* (last edited 1 week ago) by siriusmart@lemmy.world to c/programmer_humor@programming.dev

made in gimp, with <3

Context for actual rust programmersI 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 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;
    }
}

you are viewing a single comment's thread
view the rest of the comments
[-] Object@sh.itjust.works 112 points 1 week ago* (last edited 1 week 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.

[-] tatterdemalion@programming.dev 42 points 1 week ago

People who've never used Rust or only used it once and couldn't grok it like to meme that Rust is bad to cope.

[-] firelizzard@programming.dev 1 points 1 week 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.works 24 points 1 week ago

preferring Rust over Rust? what do you mean?

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

[-] firelizzard@programming.dev 4 points 6 days ago
[-] edinbruh@feddit.it 10 points 6 days ago* (last edited 6 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]
}
[-] firelizzard@programming.dev 4 points 6 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 points 6 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.

[-] firelizzard@programming.dev 1 points 6 days ago

😆 yeah I didn’t read it that hard

[-] AeonFelis@lemmy.world 2 points 6 days ago* (last edited 5 days ago)

In your defense, it's written in the only "modern" programming language that encourage this category of errors.

[-] firelizzard@programming.dev 1 points 6 days ago

I’m still far happier with it than literally any other programming language I’ve ever used

[-] First_Thunder@lemmy.zip 16 points 1 week ago

Ah yes, the good old random pile of unclear errors because you forgot to add the file in git thanks nix

[-] bobo@lemmy.ml 7 points 6 days ago

random pile of unclear errors

warning: Git tree '/path/to/repo' is dirty

[-] Ephera@lemmy.ml 3 points 6 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 points 6 days ago* (last edited 6 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.ml 2 points 6 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 points 6 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.ml 1 points 6 days ago* (last edited 6 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.

[-] bobo@lemmy.ml 2 points 6 days ago* (last edited 6 days ago)

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

It's a different error. To me it looks like you tried to import a file that doesn't exist. I made the file correctly and imported it, just didn't git add it. After committing I switched without issues.

Only the modules/terminal/new_file.nix in the second-last line is relevant.

For me that error message was in the same spot. The rest of the trace is what was evaled so you got to that error. It's the same principle as stack trace in other languages.

You don't happen to be using Lix or something, do you?

No, unstable nixos + home-manager. The error above was from

sudo nixos-rebuild switch --flake ...
[-] Ephera@lemmy.ml 1 points 6 days ago

Hmm, that sounds exactly like my setup. Weird.

I did have the file created, with {} inside (empty Nix expression). If I git add it, it works as well:

And yeah, I understand that it's supposed to be a stacktrace, but other error messages look similarly horrendous and I can often only try to guess what's wrong by reading the stacktrace top-to-bottom, so I've somewhat gotten used to doing that.

But good to know that these terrible error messages might be a problem with my system. Thanks!

[-] bobo@lemmy.ml 1 points 6 days ago

I think we're doing different things, that's why it's giving us completely different errors.

I just added files to imports in configuration.nix

I'm guessing you've got some manual error checking implemented with assertions?

error:
       … while calling the 'seq' builtin
         at «github:nixos/nixpkgs/4bd9165a9165d7b5e33ae57f3eecbcb28fb231c9?narHash=sha256-l/iNYDZ4bGOAFQY2q8y5OAfBBtrDAaPuRQqWaFHVRXM%3D»/lib/modules.nix:402:18:
          401|         options = checked options;
          402|         config = checked (removeAttrs config [ "_module" ]);
             |                  ^
          403|         _module = checked (config._module);

       … while evaluating a branch condition
         at «github:nixos/nixpkgs/4bd9165a9165d7b5e33ae57f3eecbcb28fb231c9?narHash=sha256-l/iNYDZ4bGOAFQY2q8y5OAfBBtrDAaPuRQqWaFHVRXM%3D»/lib/modules.nix:305:9:
          304|       checkUnmatched =
          305|         if config._module.check && config._module.freeformType == null && merged.unmatchedDefns != [ ] then
             |         ^
          306|           let

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: Path 'nix/bobo/test.nix' does not exist in Git repository "/home/bobo/dotfiles".
Command 'nix --extra-experimental-features 'nix-command flakes' build --print-out-paths '/home/bobo/dotfiles/nix#nixosConfigurations."bobo".config.system.build.nixos-rebuild' --no-link' returned non-zero exit status 1.

I can often only try to guess what's wrong by reading the stacktrace top-to-bottom, so I've somewhat gotten used to doing that.

I'm yet to see any nix error be more readable top to bottom. And I think it's intentionally designed that way so you don't need to scroll up.

[-] Ephera@lemmy.ml 1 points 5 days ago

I don't think, we are doing different things. I create a new file, put {} inside, then add it into the imports = [...];. It gives me that error.
Then I git add ., run again and don't get the error anymore.

Is the error you pasted now from some manual assertion you did?

[-] bobo@lemmy.ml 1 points 4 days ago* (last edited 4 days ago)

Yeah I'm doing the same, I even tried to import a nonexistent file, and use build like you instead of switch, but I'm only getting the error from above.

What's your nix version?

nix (Nix) 2.34.6

[-] Ephera@lemmy.ml 1 points 3 days ago

Hmm, for whatever reason, I'm on 2.31.4, so that might be the difference.

That version was tagged two weeks ago, because they apparently still release patch versions for rather old minor versions of nix. So, apparently I am getting updates, but I'm on some older release channel or something. No idea why.

I have to head to work now, so will have to debug in the evening or the weekend. Thanks for the clue, though.

[-] onlinepersona@programming.dev 2 points 1 week ago

Is this a comment I'm not flake enough to understand?

this post was submitted on 18 Apr 2026
472 points (100.0% liked)

Programmer Humor

31092 readers
11 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS